For two decades the answer was usually "buy." AI just dropped the cost of building enough to change which side of the line a lot of decisions fall on and created a genuine third option in between. This guide lays out the new decision math: build, buy, or assemble, chosen per capability instead of by reflex.
Where two decades of buying led: the average enterprise now runs hundreds of SaaS apps, nearly half unmanaged, more than half of licenses idle, with rising consumption-based pricing and lock-in an expensive, sprawling estate, not a cheap, safe one.
What AI changed: custom development got cheap and fast enough that "assemble" AI-generated code plus APIs plus components is now viable for problems that used to be strictly buy-only, making this a real three-way decision.
Best for commodity capabilities you don't differentiate on payroll, email, expense. Fast and vendor-maintained, if you govern the spend. Its real costs: sprawl, rising and unpredictable pricing, and lock-in.
Best for capabilities core to your differentiation, where owning the software is a strategic asset. Maximum fit and control, no lock-in at the price of the maintenance decade AI made cheaper to start but not to own.
The new middle: AI-generated code plus APIs plus components, composed into a custom-fit solution. Much of the control of building at much less of the cost best for internal tools, workflow automation, and glue between systems.
Owning it is an advantage → build or assemble. A commodity every company needs identically → buy. Don't build payroll.
A mature tool that fits without heavy customization → buy (for non-core needs). Everything on the market forces your process to bend → that misfit is a reason to assemble or build.
For buy, count sprawl, consumption/AI pricing, and lock-in. For build/assemble, count the maintenance decade, not just the AI-accelerated first version. The cheap-looking option often isn't.
The failure mode of cheap building is a swamp of unmaintained tools. Decide who owns each thing before you make it - or you've traded SaaS sprawl for shadow-IT sprawl.
No. AI lowered the cost and time of the first version of custom software, not the cost of maintaining it for years — which is where custom projects most often fail. It widens the range of decisions worth reconsidering; it doesn't make "build" automatic.
Composing a custom-fit solution from AI-generated code, third-party APIs, and existing components rather than building from scratch or buying finished. Most AI builders already work this way — generating discrete pieces they integrate.
Less than it was. The average enterprise runs ~342 apps with nearly half unmanaged and about $21M a year wasted on unused licenses, amid rising, less predictable pricing. Buying is still right for commodities — if you govern the spend.
Governance. Decide who owns and maintains anything you build or assemble before you make it. Cheap building without ownership is just shadow IT under a new name.
CTOs, VPs of Engineering, and technology leaders making build/buy/assemble decisions as AI reshapes the cost of each.
Drop your details and we'll send Build vs Buy in the AI Era straight to your inbox - no spam, unsubscribe anytime.
Talk through how this applies to your roadmap with our engineering leads - a working session, not a sales pitch.
Download White Paper