There is a version of this conversation happening in your building right now. An internal team wants to build the thing rather than pay for it. A consultant has quoted you a custom platform and used the word “proprietary” four times. Or a board member asked, in a budget meeting, why you’re renting from vendors when you could own the capability outright. The pitch is always the same underneath. Off-the-shelf is generic. Your business is special. Build it and it’s yours.
The trouble with answering is that nobody in the room has said what the alternative is. “Buy” is doing a lot of work in that sentence, and it’s covering three different products.
You are choosing between three things, not two
You can rent general capability by the seat, which means ChatGPT Enterprise or Claude or Copilot, and let your people bring the workflow to it. You can turn on the AI that already ships inside the systems you own, your CRM, your helpdesk, your ERP, or buy a product built for your industry. Or you can have software written that exists only for you.
Only the third one is a build, and it is a build whether your engineers write it or a consultancy does. That distinction carries more weight than anything else in this decision, and it is the one the pitch is designed to blur.
What you would be building is glue, and the glue got cheap
Building your own AI in 2026 doesn’t mean training a model. Almost nobody is, and the handful of companies that should aren’t reading this to find out. You’re going to call someone else’s model over an API, the same model your competitor calls.
What you would be building is everything around that call. The pipelines that feed it. The retrieval layer that gives it your documents. The evaluation harness that tells you whether it’s getting worse. The permissions, the logging, the interface your people touch. The connective tissue. A mature machine-learning system is at most five percent model and at least ninety-five percent glue.1
For years that was the argument for building. Off-the-shelf tools didn’t talk to your systems, so you built the plumbing yourself, and once you were building the plumbing you may as well build the rest. That argument is expiring. An open integration standard now connects models to internal systems, and it’s supported across OpenAI, Google, Microsoft, and AWS.2 The generic plumbing is becoming something you connect rather than something you commission.
Cheaper glue reads like an argument for building, and it would be, if the plumbing were the hard part. What commoditization actually does is shrink the buildable surface. The generic ninety-five percent is drifting toward standard parts anyone can buy, and what it leaves behind is a thin slice that is genuinely yours: your proprietary workflow and your data. That slice is smaller than any build proposal implies. It is also the only part with nobody else on the hook to maintain it.
Build versus buy is really about who absorbs the churn
This is where AI departs from ordinary software, and it is the whole decision.
When you commission a normal piece of software, the ground under it holds still. The build you pay for this year runs on roughly the same assumptions next year. AI glue doesn’t get that. It sits on a model the vendor retires on their schedule. OpenAI commits to at least six months’ notice before deprecating a generally available model.3 Six months. Every prompt your team tuned, every quirk they engineered around, every eval they calibrated, aimed at a version with an expiration date.
You also won’t be on one model. Thirty-seven percent of enterprises now run five or more in production, and the CIOs who have tried to switch describe it the same way: the prompts were tuned for one provider, and changing models became a task that eats real engineering time.4
So the honest version of this decision has nothing to do with ownership. Both options put you on someone else’s model. The difference is who absorbs the churn when that model moves.
Buy, and the vendor absorbs it. They re-tune the prompts, re-run the evals, ship you a version that still works, and spread that cost across every customer they have. Build, and you absorb it. The build has a launch date. The churn doesn’t have an end date. What gets sold as a capital project is a permanent line on your operating budget, staffed by the engineers you were going to point at something else. When you evaluate the spend, the sticker price of a build is the smallest cost it will ever have.
A vendor writing the code doesn’t make it a buy
The obvious move, once you see the staffing problem, is to make it someone else’s. Hire the consultancy. You get the custom system and they carry the weight.
MD Anderson tried the purest version of this. They paid IBM $39.2 million and PwC $21.2 million, about sixty-two million dollars, to build a custom oncology system on Watson. The arrangement was unusual in exactly the way the pitch promises: the vendors did the work, the hospital would own the result. IBM said in 2016 that the system was not ready for clinical use. It never treated a patient, and the project was shelved the following year.5
Nobody at MD Anderson wrote the code, and it failed as a build anyway. The variable that kills these projects is how custom the thing is, not whose employees typed it. Every assumption inside a bespoke system was made for one customer, so every time the ground moves, one customer pays to re-lay it. Putting a vendor’s name on the invoice changes who sends the bill. It doesn’t change who it goes to.
The market data says the same thing, narrowly. MIT’s NANDA initiative looked at three hundred public AI deployments and found that work done through purchases and vendor partnerships reached deployment about twice as often as internally built tools, roughly two in three against one in three.6 That measures one thing: systems that shipped. Shipping is a low bar, because the pilot that dies before production is a separate failure. Builds are twice as likely to die before launch. The ones that launch start paying the churn.
a16z’s survey of enterprise CIOs describes a marked move toward buying third-party applications as the ecosystem matured.4 Building is now the exception you justify, not the baseline you assume.
Two conditions, and most proposals clear neither
None of this means never build. It means the bar is narrow, and most proposals don’t clear it. Two things have to be true at once.
The first is that the workflow is something you win on. Not something you merely do. Something where doing it better than your competitors is part of why customers choose you. A general model plus a bought tool will match them on all the generic work, because they’re buying the same tool you are. Choosing tools is the decision for everything in that bucket, and that bucket is most of the org. Build only where a proprietary workflow, or a dataset nobody else has, is the edge itself. Otherwise you’re spending the scarcest talent you have to reproduce, worse and later, something you could have bought this afternoon.
The second is that you can afford to own the eval harness. Any AI work needs a cheap way to check the output, and why some workflows yield to AI and others don’t turns entirely on that. The reason it bites builders harder is amortization. A bought tool arrives with the vendor’s harness, built once and spread across thousands of customers. Build, and the harness is yours alone. Every model swap, every prompt change, every “is this version worse than the last one” argument becomes a judgment call your people resolve in a meeting, on your clock, indefinitely. That cost appears in no build proposal.
So the rule. Build where the workflow is a genuine source of advantage and you’re willing to staff the verification of it permanently. Buy everything else, which is most things. If a proposal can’t point to both the moat and the standing team, it’s a buy with a longer timeline and a bigger number.
Something to carry
Next time someone brings you a build, before you weigh vendors or budgets, make them answer two questions in plain language.
First: if a competitor bought the best tool on the market tomorrow, what would we still be able to do that they couldn’t? If the honest answer is “not much,” the workflow is generic and you should be buying the same tool they will.
Second: when the underlying model has been replaced twice and the person who tuned the prompts has left, who re-tunes them, and out of whose budget? That question has a real answer at the small number of companies that should be building. Everywhere else it produces a pause, and the pause is the decision. What’s being sold in that room is a maintenance obligation with an AI label on it.
Footnotes
-
D. Sculley et al., “Machine Learning: The High-Interest Credit Card of Technical Debt,” Google, SE4ML workshop at NIPS 2014. The “five percent model, ninety-five percent glue” framing predates the current wave but describes it exactly. ↩
-
Model Context Protocol, “One Year of MCP,” 2025. Adopted across OpenAI, Google, Microsoft, and AWS. ↩
-
OpenAI, “Deprecations,” developer documentation. Minimum notice for generally available models; specialized variants get less. ↩
-
Andreessen Horowitz, “How 100 Enterprise CIOs Are Building and Buying Gen AI in 2025.” Source of both the multi-model figure and the shift toward buying. ↩ ↩2
-
Eliza Strickland, “How IBM Watson Overpromised and Underdelivered on AI Health Care,” IEEE Spectrum, 2019. The $39.2M / $21.2M split is from the 2016 University of Texas System audit, reported by Forbes. ↩
-
MIT Project NANDA, “The GenAI Divide: State of AI in Business 2025.” The build-versus-buy split measures reaching deployment, not value produced, and reads as directional rather than precise. ↩