Photo: Google Gemini · AI-generated
For two decades, the default answer to “build or buy?” was buy. Licensing an established platform meant proven functionality, vendor support, and a fraction of the cost of an in-house team. Building was the exception, reserved for whatever was genuinely core to the business. That default is shifting. A 2026 build-vs-buy report from Retool found that 35% of teams have already replaced the functionality of at least one SaaS tool with something built in-house, and 78% plan to build more custom tools this year. AI-assisted design and coding tools are the reason — and the shift is rational, not reckless, if you understand what actually changed.
The old logic assumed building was expensive. It still is — just less than before
Off-the-shelf enterprise and business software is built for the average customer, not your organization. Every configuration option, every workflow, every field on every form is a compromise between what you need and what thousands of other customers also need. Getting it to actually match how your business runs means expensive consulting-hour customization — and even then, the result is rarely a perfect fit. The underlying data model, the assumptions baked into the workflow engine, the places where the vendor’s opinion about “how this process should work” doesn’t match yours: those don’t go away with configuration. They get worked around, and the workaround becomes a permanent, quietly expensive tax on the process it was meant to fix.
That was always true. What’s changed is the other side of the comparison. AI-assisted coding tools have meaningfully lowered the cost and time of building a purpose-built application — not by replacing engineering judgment, but by compressing the mechanical parts of it: boilerplate, scaffolding, first-draft implementations of well-understood patterns. A purpose-built internal tool that would have needed months of budget to justify two years ago can now be scoped, built, and shipped in weeks. That’s the actual tilt: build was always more precise, buy was always faster to start — and the gap in the “faster to start” column just closed substantially.
Two lightweight examples
Consider a vendor-onboarding approval flow: three departments need to sign off in a specific order, with different exception paths depending on vendor risk category and contract size. A generic procurement platform can usually approximate this — with enough configuration, a consultant, and a few months. A lightweight, purpose-built approval tool that encodes exactly those three steps and exactly those exception paths can be built directly against how the organization actually works, in a fraction of the time, with no configuration debt to maintain later.
Or consider two systems that each do their job well but were never designed to share data — an inventory platform and a sales-channel tool, say, using different SKU schemes and no common identifier. Buying a third platform to sit on top rarely resolves this cleanly; it just adds a third opinion about how the mapping should work. A small, purpose-built reconciliation layer that understands both systems’ actual data — built once, understood completely — usually serves the business better than a generic BI tool asked to guess at a mapping it wasn’t designed for.
What this looks like when we build it
These aren’t hypothetical. A Purchasing Portal we built extended a manufacturer’s existing Sage 100 ERP with a purpose-built purchasing workflow — rather than forcing a generic procurement module to match a process it wasn’t built for — as a Full Application Lifecycle Management engagement for a Mid-Sized Business in Industrial Machinery. A Visitor Compliance App replaced generic visitor-management software with a compliance workflow built to match a manufacturer’s exact regulatory obligations across multiple sites. A Supply-Chain Intelligence Platform gave a garment manufacturer the reconciliation layer between two systems that a third off-the-shelf platform couldn’t have provided, on Time & Materials. And ReportSync — a small, purpose-built sync tool for a chemicals-sector client — has run for years under Managed Support & Maintenance, doing exactly one job well instead of being a corner of a platform doing many jobs adequately.
The part AI does not shortcut
None of this means build-everything is now the safe default. AI-assisted tools lower the cost of writing code; they do not lower the cost of writing code that survives contact with a real organization’s edge cases, still works after the requirements change twice, and doesn’t quietly become the thing nobody understands once its author leaves. That part is still engineering — deciding what to build, not just how fast to type it. It’s also the part off-the-shelf software genuinely gets right by default, and the part a rushed internal build most often gets wrong.
The organizations getting real value from this shift are the ones treating “build” as a serious custom software development decision, not a weekend project — pairing AI-assisted tools with people who know how to use them, on the specific process that off-the-shelf software was never going to fit. Tell us what your off-the-shelf tools are fighting you on — we’ll tell you honestly whether building around it is worth it.