Build vs Buy in the Age of the $2.5 Trillion AI Bust

On 28 May, Gartner said the quiet part out loud: most generative-AI and custom-model projects will be a bust. Organisations that set out to build their own models, the analysts warned, "will abandon their efforts due to costs, complexity and technical debt." They said this in the same season they forecast that the world will spend $2.5 trillion on AI in 2026. Record investment and record disappointment, announced in the same breath. I have read that sentence several times now, and each time it lands the same way. Not as a prediction, but as a description of conversations I am already having every week.

The most expensive question in the room

I run an AI-governance consultancy, EthicaLabs. I founded a wellness platform, CIGMA, and its companion, MOA. I am building a health venture called WhatsHealth, and I sit on the partnerships side of Partners In Digital Health. Across every one of those tables, in boardrooms and on video calls, the same question keeps surfacing. It is rarely phrased the same way twice, but it always reduces to four words. Do we build or buy?

It sounds like a procurement question. It is dressed up as one, with its talk of total cost of ownership, integration timelines, licence fees and head-count. Yet after thirteen years in digital health I have come to see it as something else entirely. It is the most expensive question in the room because the cost of answering it wrongly is almost never the cost you budgeted for. You budget for software. You pay in months, in morale, and sometimes in the trust of the very clinicians or patients you were trying to serve. And in health, that last currency is the one you can least afford to spend, because you rarely get it back.

What the data is quietly telling us

The numbers, when you line them up, are sobering. MIT's NANDA research found that 95% of AI pilots fail to deliver any measurable business impact. BCG and Forrester put it differently but no more gently. A full 88% of agentic pilots never reach production at all. S&P Global reported that 42% of companies abandoned most of their AI initiatives in 2025, up sharply from the year before. These are not the statistics of a technology that is failing. AI is not failing. These are the statistics of organisations reaching for the wrong tool, or building the wrong thing, at enormous expense.

What strikes me is that the failures cluster around ambition rather than capability. The teams that decided to build everything, to train their own models, to stand up their own orchestration, to own the entire stack, are disproportionately the ones now quietly winding projects down. Not because they lacked talent, but because they mistook building for differentiation, and discovered eighteen months in that they had spent a fortune rebuilding something they could have bought in an afternoon. By the time a custom build limps into production, the median pilot has already taken the better part of half a year, and the commodity tools it set out to beat have been upgraded twice.

The mirror image is just as real, and I have watched it ruin teams too. The organisations that bought everything, that handed the whole problem to a vendor and assumed the logo on the contract was a guarantee, found themselves trapped inside tools they could not change, holding data they could not fully reach, paying for a roadmap that was never theirs to steer. And when the bought tool is too rigid to fit how people actually work, they do not stop working. They route around it. Shadow AI, the unsanctioned tools employees reach for when the official one frustrates them, has surged in some industries by as much as 250% in a single year. You can buy a platform. You cannot buy compliance with it.

The question underneath the question

So I have stopped answering "build or buy" as if it were a binary. It almost never is. The honest answer, the one I now give before anyone has finished asking, is this. Buy the commodity, and build the moat.

Almost everything in a modern AI system is commodity. The model is commodity. The vector store is commodity. The transcription, the embeddings and the orchestration scaffolding are commodity too, improving and cheapening every quarter whether you touch them or not. Gartner now expects 80% of software vendors to embed generative AI in their products by the end of this year, against less than 1% in 2023. The plumbing is being commoditised at a speed no internal team can match. Building your own version of it is not strategy. It is a very expensive hobby.

What is not commodity is the thin, precious layer that only you can build. Your proprietary data, your clinical workflow, your particular patients and their particular needs, the judgement of people who have spent years in your domain. In healthcare especially, the teams getting this right are landing in the same place almost without exception. They buy at the commodity layer, the electronic record and the claims processing and the infrastructure, and they build only at the intelligence layer, where their own denial patterns and formularies and populations make a generic model useless. That is the line. Everything below it, buy. Everything above it, build. The skill, the entire skill, is knowing where the line sits in your organisation, because it sits in a different place for each of us.

The third answer almost nobody plans for

Here is what the binary framing hides, and what the last two years have quietly changed. The teams that succeed are almost never pure builders or pure buyers. They are assemblers. Not long ago the sensible split was to buy 70% to 80% of the stack off the shelf and build only the thin remainder. That number is falling fast. In today's world of AI builders, where a capable team can stand up in a weekend what used to take a quarter, you can realistically build half of your solution yourself. The split I now recommend is closer to 50% to 60% bought and 40% to 50% built. You buy the model, the infrastructure and the standard components, and then you build the last mile that no vendor can know: the retrieval over your own records, the prompts encoded with your own clinical logic, the guardrails your regulators demand, the human-in-the-loop checkpoints where a clinician must stay in charge. The bought part gets you to the starting line in days. The built part, now larger than it has ever been, is deliberate and entirely yours.

And because you are buying less, you must buy far more carefully. My recommendation is simple to say and hard to practise. When you buy, beware of lock-in. Buy scaffolding, not a harboured, sealed solution that quietly takes ownership of your logic and will not let it leave. Buy agnostic capabilities, the kind you can swap, export, and re-point at a different provider next year without dismantling your business to do it. The questions change accordingly. Can I export my data and my logic? Can I reach the layer underneath the polished interface? If this vendor doubled their price or disappeared tomorrow, what exactly would I still own? The worst outcome in this field is not building too much or buying too much. It is buying something so closed that you can never build the only part that was ever going to matter. I have signed contracts I later regretted for exactly that reason, and I have learned to read the terms of exit before I admire the quality of the entrance. A foundation you cannot leave is not a foundation. It is a mortgage on every decision that comes after it.

What thirteen years taught me

When I built CIGMA, I did not build a database engine, an authentication system or a video pipeline. Those are solved problems, and solved better by people whose entire company is that one thing. What I built, what I would not let anyone else build, was the part that makes CIGMA itself. The way it holds a person in a vulnerable moment, the editorial judgement of MOA, the decision about when technology should step back and point someone towards a human being. No vendor could have built that, because no vendor has my reason for building it. With WhatsHealth I am making the same call again, faster this time, because the discipline gets easier with practice. I buy the infrastructure without sentiment, and I guard the small clinical core as if the whole venture depends on it, because it does.

That is the test I now apply, and I offer it to anyone weighing the same decision. Ask not "can we build this", because you almost always can. Ask instead, "if we buy this, do we lose anything that is actually ours?" If the answer is no, buy it, and spend the saved energy on the thing that is genuinely yours. If the answer is yes, if buying means surrendering the one capability that is the reason your organisation exists, then build it, build it properly, and do not apologise for the cost. The mistake is not building. The mistake is building the commodity and buying the moat, which is precisely backwards, and precisely what most of those failed pilots did.

When your vendor quietly becomes your strategy

There is a harder edge to buying, and last year gave us its defining example. Builder.ai, a company valued at $1.5 billion on the promise that its AI could build your software for you, collapsed into insolvency. When the reporting was done, it emerged that the celebrated AI assistant was, to a significant degree, several hundred human engineers assembling code by hand, and that revenues had been overstated by something close to 300%. Customers, many of them small businesses, were left scrambling. Some were unable even to retrieve their own source code as the platform went dark.

I hold that story up not to mock a failed company, but because it is the cleanest possible illustration of a risk we systematically underprice. When you buy, you are not only buying a capability. You are buying a dependency. You are betting that the vendor will still exist, still function, and still act in your interest, for as long as the thing you built on top of them needs to keep running. A domain-locked agent can take six to twelve months to migrate off a failing platform, if you can migrate it at all. In healthcare the stakes climb higher still, because the dependency is wrapped around patient data, and you cannot simply switch it off while you shop for a replacement.

This is why, in healthcare, the ground is shifting under everyone's feet. As Epic and Oracle embed AI directly into the records that hospitals already run on, your electronic-record vendor is quietly becoming your AI vendor too, whether you chose them for that or not. That is a profound concentration of dependency, and it deserves to be a deliberate decision rather than a default. It is also why I watch the quiet rise of small, domain-specific models with real interest. A focused model you can run on your own terms, trained for one clinical task, is often cheaper, easier to govern, and safer with protected health information than a vast general system you rent and cannot inspect. The teams I trust most are now treating portability as a design requirement from the very first day. They own their data, they keep their logic in exportable form, and they refuse to let any single vendor become load-bearing for their entire strategy. Buying is not the opposite of caution. Buying carelessly is.

The Sentence Worth Holding Onto

We are living through the most expensive season of build-versus-buy in the history of our field, two and a half trillion dollars of it, and the data already tells us how most of it ends. Yet the failures are not really failures of building, or of buying. They are failures of discernment, of teams that could not say, clearly and early, which part of their work was theirs and which part was the world's. The technology will keep getting cheaper and better. The discernment will not arrive on its own.

So here is the sentence I would ask you to hold onto, the one I now reach for before anyone has finished asking the question. Buy what makes you the same as everyone else, so that you have the time and the courage to build what makes you different. Get that line right, and the two and a half trillion dollars stops being a warning. It becomes the cheapest tuition you will ever pay.