I have sat in a lot of rooms where a company talked itself into building its own AI. The meetings have a tell. Someone on the engineering team spent a weekend wiring up a demo, the demo works, and by the time everyone files out of the room there is a plan to build the real thing in-house. Somewhere in the excitement, buying the same capability from a vendor started to feel like admitting defeat. Nobody has asked the boring question, which is whether you could have just bought it and gotten on with your life.
I spent close to fifteen years at McKinsey and Deloitte doing technology strategy, and build versus buy is one of the few calls in this work where the data actually takes a side.
MIT looked at hundreds of enterprise AI efforts in 2025 and found that ninety-five percent of them produced no measurable return at all. The finding that got less attention is the one that matters here: the AI that companies bought from vendors reached production far more often than the AI they built themselves.
This is not a talent problem. The people building in-house are often the sharpest engineers in the building. The gap is about what you actually sign up for when you build, which turns out to be a lot more than fits in a demo.
What building AI actually commits you to
When you buy software, keeping it alive is the vendor’s problem. When you build, it is all yours, and it is yours for good. The model, and the bill to retrain it. A data pipeline that feeds it and snaps the day some upstream system renames a column. The evaluation setup that tells you whether it still works. Then the security review, the monitoring, and the on-call shift for the week it starts confidently making things up in production.
None of that is in the demo. It shows up about eighteen months later, usually right after the person who built it takes a job somewhere else, and the whole thing starts quietly rotting because keeping it running was never really anyone’s job.
RAND put the failure rate for AI projects north of eighty percent in 2025, roughly double the rate for technology projects that have no AI in them. Building your own takes every one of those ways to fail and hands them to a team that already has a full-time job doing something else.
The two mistakes are mirror images
Companies that get this wrong tend to get it wrong in one of two directions, and the two are opposites.
The first is overbuilding. A team sets out to build a document summarizer, or an internal chatbot, or a copilot for the support desk. These are commodities now. A dozen vendors sell a better one, keep it running, and ship improvements every quarter you do not have to staff. Building your own version means spending your best engineers to get a worse result, later, that you then get to babysit forever.
The second is overbuying. A company takes the one thing that could genuinely set it apart, the capability that runs on its own data or its own particular way of working, and buys a generic tool to do it. The tool works fine. It also works exactly as well for every competitor who buys the same license. You have spent real money to reach a tie on the one dimension where you could have been ahead.
I watched both mistakes happen at once during a competitive analysis I ran for a company that builds the installed sound systems for big theme parks and concert venues. Its competitors had built something genuinely hard: an AI layer, trained on their own acoustic data, that could simulate how a venue would sound before anyone poured the concrete. No vendor sold that. It was a real moat. My client had gone the other way. It had bought a stack of off-the-shelf copilot licenses, put “AI strategy” on a slide, and could not work out why it kept losing deals. The hardware was never the problem. One side built where it had an edge and bought everything else. The other bought everything and built nothing, then wondered why it looked exactly like the competition.
The build decision turns on one question: whether the capability runs on something only you have.
The question that decides it
You can settle most of this with one question, and you can settle it before anyone writes a line of code. Does the capability run on something only you have?
Proprietary data nobody else can get. A workflow that is truly your own. A distribution channel, a regulatory position, decades of institutional knowledge no vendor can see. If your capability sits on one of those, and it is central to how you actually win, now you have a reason to build.
If it runs on the same public models and public data your competitors can rent by the month, rent it too. Nobody hands out a prize for building your own version of something the whole market can already buy.
The buy side has a trap too
Buying has its own way of going wrong, and it is worth saying out loud so nobody uses it as a reason to go build instead. Companies buy tools they never actually switch on. The copilot seats nobody logs into. A platform whose usage-based pricing climbs faster than anything it produces. That three-year contract somebody signed in a hurry.
S&P Global found that forty-two percent of companies walked away from most of their AI projects in 2025, up from seventeen percent the year before, and that the average company killed nearly half its proof-of-concepts before they reached production. A lot of that is just bad buying. Tools bought with no rollout plan, no owner, and no number they were meant to move.
The fix for a bad buy is a better buy. A tighter contract. A real rollout plan. A renegotiation. A vendor you actually hold to a result. Building your own tool to escape a vendor you never managed in the first place is the most expensive way to solve a problem you made yourself.
The same logic sits underneath the tools you do buy. McKinsey found that most organizations have adopted AI, yet nearly two-thirds have not begun to scale it across the enterprise, because the return comes from rewiring the organization around the tool. The license is the easy part. McKinsey’s work on agentic AI says it plainly: you can buy the model, but the foundation that turns it into a result, the data and the governance and the workflow and the people, is the part you build. The purchase order is where the work starts.
The filter for the next build decision
The next time someone pitches building AI in-house, run it through four questions before anyone approves a budget.
The Build Test
- Can a vendor sell us this today? If yes, buying is the default, and the people who want to build have to prove why not.
- Does it run on data or a workflow no competitor has? If no, you are rebuilding a commodity. Don’t.
- The build takes three months; keeping it alive takes three years. Can we staff the three years? If not, don’t start.
- If we build it and it flops, and four out of five do, what did that cost us? If the answer is a year and a team, buy.
Sometimes building is the right answer, and when it is, it is one of the highest-return things a company can do, because a capability your competitors cannot rent is an advantage that lasts. But it is the exception, and it should have to earn its place against the default, which is to buy the boring commodity and spend your scarce build budget on the one thing that is actually yours.
How RLK Can Help
My AI Diagnostic maps where your AI money is going and whether any of it is earning its keep, which is usually the moment the build-versus-buy pattern shows up in plain sight. The AI Strategy and Capital Allocation engagement is built for exactly this decision: where the budget should go, what to build, and what to buy. And when the trouble sits on the buy side, the Vendor and Spend Strategy engagement goes after the value trapped inside tools you already pay for. Start the conversation.
Sources
- MIT NANDA, “The GenAI Divide: State of AI in Business 2025”
- RAND Corporation, “Why AI Projects Fail and How They Can Succeed”
- S&P Global Market Intelligence, “Generative AI Shows Rapid Growth but Yields Mixed Results”
- McKinsey & Company, “The State of AI: How Organizations Are Rewiring to Capture Value”
- McKinsey & Company, “Seizing the Agentic AI Advantage”