Buy the commodity, build the difference

Build vs buy AI: which one is right?

Buy by default. Build only where the capability is a genuine differentiator and you hold data nobody else has. The market has already settled into that shape: 76% of enterprise AI use cases were bought rather than built in 2025, up from 53% in 2024,¹ and roughly 70% of enterprise use cases are served adequately by off-the-shelf products.⁴ A build vs buy AI decision is therefore not a contest between two philosophies. It is a test of whether this one use case falls in the minority that repays a build.

Two things decide it. The first is cost, and the cost that matters is the annual one, not the launch one. The second is control, which almost every executive asks for and very few define. Answer the second properly and the first usually answers itself.

What is the real custom AI cost, and what does buying cost?

Custom enterprise AI platforms typically run $300,000 to $1.5 million or more upfront, plus 20% to 30% of that annually for compute, updates and monitoring.⁵ The upfront figure is the one that reaches the board paper. The annual figure decides whether the build was sound, because it does not stop, it does not fall away when attention moves elsewhere, and it is paid in the scarcest currency you have, which is engineering time.

Set the two paths against each other on the lines that actually move.

The line most cost models leave out is the fourth. A bought tool’s roadmap moves with the vendor’s entire customer base. A built tool’s roadmap moves only as fast as the team you can staff for it, and base models now turn over every few months. That churn punishes slow internal builds harder than anything in the subscription column, and it is the reason a build that looked cheap in year one looks expensive in year three.

One correction to the standard advice. Agentic coding tools have pulled the build cost curve down faster than the buy curve has moved, which is why narrow, high-value builds deserve a fresh look even as aggregate spending tilts toward buying. The change is real at the scale of a single workflow. It has not made a platform build cheap.

Why has enterprise spending swung so hard toward buying?

Because scale arrived before certainty did. Enterprise generative AI spending reached $37 billion in 2025, up 3.2 times on the previous year.¹ At that rate of increase, most buyers were choosing between shipping something inside the quarter and staffing a build that would land after the requirement had already moved.

Read the reversal precisely, because the popular version of it is wrong. It does not say building is dead. It says the median AI use case turned out to be a commodity workflow that somebody already sells: retrieval, ticket triage, code assistance, document extraction, meeting notes. Nobody wins a market by owning a slightly better version of a feature that ships in four competing products. The genuine build candidates did not disappear. They stopped being the default.

Does build vs buy AI change the odds of the project working?

It moves them, though less than the headline suggests. Vendor-led AI projects succeed at roughly 67% against 33% for pure in-house builds.⁴ That is a real two-to-one gap, and most of it reflects who has already made the mistakes once rather than any property of the code.

Then comes the number that overrides both columns. MIT’s research on what it calls the generative AI divide found 95% of pilots delivering no measurable profit and loss return,² with only about 5% extracting value in the millions.³ Crucially, the failures did not sort by origin. Pilots that stayed bolted onto an existing workflow failed whether they were built or bought. The small group that worked were embedded deep enough to change how the work was actually done.

The 95% is not a build problem or a buy problem. It is an integration problem, and integration is a governance and change management cost that build vs buy analyses almost always leave out.

The practical consequence is a line item. Put the workflow redesign and change management budget into the business case before the vendor fee or the platform cost, because that is the spend that separates the two outcomes. The same pattern holds in back-office automation, where the projects that keep their gains are the ones that redesigned the process instead of layering a tool on top of it.

The control question: what are you actually asking for?

When executives say they want control, they usually mean tailoring. That is the less important half. 94% of IT teams report concern about vendor lock-in,⁸ and lock-in has little to do with how much of the interface you can reconfigure. It is the switching cost, financial, technical and data-related, that makes leaving expensive once the tool sits inside a core workflow.

The variable worth testing is data exit. If you left in eighteen months, could you extract your fine-tuning data, your prompt library, your evaluation sets and your usage history in a form another system could read? If the answer is no, switching is a second build project and you have bought a capability at the price of an option you cannot exercise.

This is not hypothetical. 35% of enterprises have already replaced at least one SaaS tool with a custom build, and 78% expect to build more custom internal tools this year.⁷ Buying today does not commit you to buying forever, but only if the exit was designed at signature rather than discovered at renewal. Three questions cover it:

• Data exit. Which data leaves with us, in which formats, and how many working days does extraction take?
• Ceiling. At what point does our requirement stop being configuration and start needing the vendor’s roadmap to move?
• Dependency. If this vendor doubled its price or was acquired, what is our plan, and who has costed it?

How should you run AI vendor selection?

Start with a fact that flatters the buy case, then use it against your shortlist. AI deals convert to production at 47%, close to double the 25% rate of traditional SaaS deals.¹ Buyers are moving from trial to rollout faster than they ever did with conventional software, which leaves a much shorter window to find the things that matter. AI vendor selection has to be compressed without becoming shallow.

Six questions do most of the work in that window.

1. Which decisions does the system take alone, which does it escalate, and what triggers the escalation? Ask for the boundary, not the demo.
2. Is our data used to train models that serve other customers, and can that be switched off contractually rather than by setting?
3. What happens at the next base model generation? Who pays for the migration, and what notice do we get before a model we depend on is deprecated?
4. Show us an audit trail from a real failure. A governance module is a checkbox until it produces a record somebody can follow after something went wrong.
5. Name the export formats and the elapsed time to produce a full data extract, and put both in the contract.
6. Give us a reference customer at our scale and in our regulatory context who has been live for more than a year, not a pilot.

A vendor who answers the first four crisply is usually a safer bet than one with a longer feature list, because those four are the answers that only exist if other customers have already pushed the product past the demo.

A build vs buy AI framework you can run this week

Sort every candidate use case on two axes and nothing else. Is the capability a commodity or a differentiator for us? And does it run on data or a process that nobody outside this company holds? Those two questions place almost every case correctly.

Most mature answers end up hybrid: buy commodity infrastructure and foundation model access, build the thin application or integration layer that carries the proprietary logic. That combination buys vendor speed on the parts nobody differentiates on, and keeps the part that is genuinely yours under your control.

The sequencing rule matters more than the quadrant. Validate with something you can rent before you commit to something you have to maintain. The 14 month pattern in failed builds⁶ almost always traces back to a skipped scoping step, not to bad engineering. If the shortlist is unclear or the use cases have not been sorted yet, our AI consulting team runs that classification as a bounded piece of work, and the same logic governs the sequencing of a wider AI transformation roadmap. Tell us which use case is first in the queue and we will tell you whether it is a build.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.