AI Implementation: Build or Buy in 2026

Almost every AI implementation I am called into comes down to one quiet decision the client did not know they were making: build or buy. After years of doing this work, my answer is unromantic. Buy the boring eighty percent that everyone needs and nobody remembers. Build only the rare twenty percent that is genuinely yours. Get that split wrong and the project struggles no matter how good the technology underneath it is.

Build or buy is the decision that quietly decides your AI implementation

On paper, build-versus-buy looks like a procurement footnote, a box someone ticks after the real strategy is done. In practice it is the load-bearing choice of the whole project. Most of the failed implementations I am asked to rescue did not fail on the model or the data science. They failed because a company built something it should have bought and drowned in the maintenance, or bought something it should have built and never got the one capability that would have set it apart.

Let me define the terms the way I use them with a client. Buying means taking an existing tool or platform and configuring it to your process. Building means commissioning something custom — code, prompts, orchestration — that did not exist before you paid for it. The real world is almost never pure. The interesting question is where you draw the line, and the market is quietly converging on the same answer: a recent read of the field found that fifty-seven percent of organisations now favour a blended build-and-buy approach, up from fifty-one percent just a quarter earlier. Purity is losing. The mix is winning. The only thing worth arguing about is the ratio.

What got cheap in 2026 — and what did not

The reason this decision feels different in 2026 than it did two years ago is that the plumbing got cheap. The Model Context Protocol went from a niche idea to something close to a standard: by mid-2026, around forty-one percent of software organisations were running MCP servers in production, the SDKs were being downloaded roughly ninety-seven million times a month, and there were well over nine thousand public servers you could plug into. Agent frameworks are a commodity now. Connecting a model to your tools, which used to be a project in itself, is closer to an afternoon.

Here is the trap that cheap plumbing sets. It makes building look cheaper and faster than it has ever been, so more companies talk themselves into building. But what got cheap was the connective tissue, not the ownership. Gartner expects more than forty percent of agentic AI projects to be cancelled by the end of 2027, and the reasons it gives are not plumbing problems — they are escalating costs, unclear business value and governance gaps. Those live in the parts of a build that never got cheap: the judgement about what to build, and the years of owning it afterwards.

Buy the boring eighty percent

My first instinct on almost any capability is to buy it, and I mean that as a compliment to the work, not a shortcut around it. The rule is simple. If a capability is the same for you as it is for your competitor, buy it. Transcription is the same. Generic document extraction is the same. A helpdesk assistant that answers the twenty most common questions is the same. Off-the-shelf tools now cover something like seventy percent of use cases and can be configured and live in one to three weeks. Choosing to buy those is not settling. It is refusing to pay your own people to reinvent a wheel that already rolls perfectly well.

This is the part of the conversation where founders sometimes deflate, because buying feels less impressive than building. I understand the pull. But nobody has ever been out-competed because their meeting notes were transcribed by a tool with someone else's logo on it. When we map a company's processes in an AI scan, most of what we find is commodity work dressed up as something special. Naming it as commodity is the point. It frees the budget and the attention for the small number of things that actually deserve a custom build. That reframing — not the code — is most of what an AI consultant for the mkb is really for.

There is a second, quieter argument for buying that founders miss. When you buy, someone else pays to improve the product. The vendor's whole business is making that transcription or that helpdesk model better every quarter, and you get those gains for the price of a subscription. When you build, every improvement is yours to fund. For a commodity capability that is a losing race: you are spending scarce engineering time to keep pace with a company whose entire reason to exist is to outrun you at exactly that task. Buy it, and let their roadmap be your roadmap.

Build the rare twenty percent

So when do you build? I use three tests, and the candidate has to pass at least one convincingly. First, proprietary data: if the thing gets meaningfully better because of data only you have, that is a reason to build, because no vendor can train on what it cannot see. Second, a genuinely peculiar workflow: if the way you work is odd for good reasons, a process no off-the-shelf product models because almost nobody else does it, a build can capture that. Third, data you cannot hand over: banks build their own agents partly because exposing transaction data to a third party is unacceptable, and a custom system lets them keep explicit rollback logic and strict access control.

To make the twenty percent concrete: it is rarely a whole product and almost always a sliver. A logistics firm does not build its own chat model; it might build the one piece of routing logic that encodes forty years of knowing which drivers handle which awkward addresses. An accountancy practice does not build its own document reader; it might build the layer that maps a messy client folder onto its own particular way of filing. The rare part is small, specific and unglamorous, which is exactly why it survives contact with a vendor's catalogue. If a competitor could describe your candidate for a build in the same words you would, it is not the rare part.

What you are buying when you build is not just the feature. You are buying the obligation to own it. A basic custom build runs something like six to fifteen weeks before it earns a euro, and after that your team carries the optimisation, the evaluations, the model swaps and the slow drift of a system that was accurate in March and quietly is not by September. That obligation is worth taking on for the twenty percent that is your edge. It is a terrible trade for the eighty percent that is not. Before any build I still push a client to scope a small proof of concept first, so the obligation is proven in miniature before it is signed for at scale.

The real cost is not the build — it is the year after it

The single most common budgeting mistake I see is quoting the build and forgetting the year that follows it. The build is the cheap part. What costs real money is everything that happens once the thing is in production: the evaluations that tell you it is still right, the on-call for when it says something confidently wrong to a customer, the retraining when a model you depend on is deprecated, and the small governance apparatus the EU AI Act now expects you to keep. When people ask me what a custom build really costs, I point them at the total cost of ownership, not the invoice for version one — because that invoice is the smallest number in the story.

People underestimate this because software has trained them to expect that finished means done. A bridge, once built, mostly stands there. A custom AI system is more like a hedge: leave it alone for two quarters and it grows wild. The models it sits on change, the data drifts, and the edge cases you never saw in testing arrive in production wearing a customer's name. None of that is a reason never to build. It is a reason to count it before you start, so the maintenance is a decision you made rather than a surprise you inherited.

This is also why the build-or-buy line moves over time for the same company. Something that was worth building in 2024 can become worth buying in 2026, because the market caught up and a vendor now maintains it better than you can. A mature AI practice revisits its own splits. It is not embarrassing to retire a custom system you were once proud of. It is embarrassing to keep paying to maintain one that the market has commoditised underneath you while you were not looking.

How I run the build-or-buy decision with a client

The framework I actually use fits on the back of a napkin. Write the workflow in plain language, the way you would explain it to a new hire. Ask whether it looks the same at your closest competitor; if it does, that is a buy. Ask whether your own data or your own way of working would make it meaningfully better than a vendor's version; if the honest answer is no, that is also a buy. Only when a capability clears both bars, different from the competition and improved by something that is uniquely yours, do we talk seriously about building. The default is buy, and a build has to earn its way out of that default.

Most of the value in this conversation is in slowing it down. When I end a discovery call quickly, it is usually because we established in twenty minutes that everything on the table was a buy and there was no honest custom project to sell. That is a good outcome, even though it is a smaller invoice. Sometimes the right answer is to do nothing custom at all, to buy three tools, train the team and revisit in six months. A consultant whose only product is a build will never hand you that answer, and it is the answer that has saved my clients the most money.

Three ways the build-or-buy call goes wrong

The first failure is building for prestige. A company builds its own version of a commodity because “we built our own” sounds good in a board meeting, and then spends three years maintaining a worse copy of a tool it could have rented. The second is the accidental build: a company buys a platform, then customises it so heavily that it now owns a bespoke system without ever deciding to, taking on all the maintenance cost of building with none of the clarity. The third, and the most expensive, is splitting the wrong way round: buying the rare thing and building the boring one. Handing your genuine edge to a shared vendor while pouring custom budget into transcription is how you end up with a project that is busy, costly and strategically pointless.

When I say I can often tell a project will fail before it starts, this is one of the tells. If a company cannot say, in one sentence, which twenty percent of the work is theirs and why, the split has not been made — and an unmade split does not disappear. It just gets made badly, later, by whoever shouts loudest. Getting build-versus-buy right is not a technical skill. It is the discipline to be honest about which parts of your business are actually special, and to refuse to spend a custom budget on the parts that are not.

None of this is anti-building. I run a consultancy that builds custom AI for a living. It is a plea to build on purpose: to spend the scarce, expensive effort of a real build only where it buys you something the market cannot sell you, and to buy the rest without shame. In 2026, with the plumbing cheaper than it has ever been, that discipline is the whole game.

Frequently asked questions