Build or buy: how I decide on an AI feature

Every roadmap conversation I have been in this year has had a version of the build-versus-buy question in it, and almost all of them started in the wrong place. Somebody demos a tool, somebody says we could build that, and two weeks vanish into a comparison spreadsheet that answers a question nobody should have asked.

Build-versus-buy is not one decision. An AI feature is a stack of layers, and the honest answer is usually build some and buy some. The work is figuring out which.

The layers

Six of them, and they behave differently.

The model. The thing that infers. Almost nobody should build this now, and the small number who should already know why.

The data. What the model sees. Your documents, your transactions, your history, your labels.

The workflow. Where the feature sits in what someone was already doing. When it fires, what it interrupts, what it replaces.

The interface. How the output is presented, and how confident it is allowed to look.

The evaluation. How you know it works, and how you find out when it stops.

The governance. Who is accountable, what the oversight actually is, and what your regulatory role is.

Draw those six for any feature on your roadmap and the decision usually settles itself. The model is a commodity you rent. The data and the workflow are unrepeatable and specific to you. Evaluation and governance are where most bought solutions are thinnest, which is exactly why they are where most bought solutions fail after the pilot.

The four tests

Does the value depend on your data?

If the feature is only good because it has seen your history, your labels, or your transaction patterns, then whatever you buy is a shell you will fill yourself. That is fine, and it is often the right move, but price it honestly. You are buying a starting point and building a product.

If the value comes from general capability that any competitor could rent tomorrow, you have no reason to build and no defensibility if you do.

Is the failure mode yours to own?

Ask what happens when it is confidently wrong. If a wrong output means a mildly annoyed user, buy it and move on. If a wrong output means a bad credit decision, a missed compliance obligation, or a customer told something untrue about their own money, then you are going to own that failure whoever built the thing. Owning a failure you cannot inspect is the worst position available.

This test kills more vendor demos than any other, and it kills them for a good reason. A demo shows the happy path. Failure modes are the product.

Can you evaluate it?

If you cannot measure whether it works on your cases, you have not bought a feature, you have bought a claim. Before any purchase I want to know what a good answer looks like on our data, who decides that, and whether the vendor will let us run our own evaluation set against it rather than theirs.

A vendor who will not let you test on your own cases is telling you something. Listen to it.

What is your regulatory role?

This is the test that gets skipped, and it is the expensive one. Buying does not automatically settle your position under the EU AI Act. You can become the provider of a system you bought, if you put your name on it or substantially modify it, which is precisely the thing product teams do to a bought tool in month three. Even where you stay a deployer, some obligations sit on you directly and not on your vendor. Under Article 50, disclosure of deepfakes and of AI-generated public-interest text is the deployer’s duty, whoever built the model.

So this test has a build-versus-buy consequence that runs the opposite way to intuition. Buying can leave you carrying obligations for a system you cannot see inside.

The thing that goes wrong most often

Teams buy the demo and build the integration.

The tool is genuinely good at the thing it was demonstrated doing. Then it meets your identity system, your data residency requirements, your security review, your existing workflow, and the two hundred edge cases in your domain that nobody in the demo had heard of. Six months later there is a team of three maintaining an integration layer that is larger than the feature would have been.

I do not think this is avoidable by being cleverer about vendor selection. I think it is avoidable by scoping the integration honestly at decision time and putting it in the buy column, where it belongs. A buy decision that hides its own integration cost is not a buy decision, it is an estimate everyone has agreed not to look at.

Sizing, and why most teams cannot do this test at all

None of the above helps if nobody has sized the value. BCG’s July 2026 survey of 152 CEOs at companies with revenues of at least $500 million found that more than half named linking AI initiatives to the P&L as a key barrier, while only 14% had clearly defined the P&L impact for all their AI initiatives. Nearly two thirds run AI pilots, and 26% have embedded AI into a broader business transformation.

A build-versus-buy decision is a value-per-cost comparison. If the value side is undefined, the comparison is theatre, and the decision defaults to whoever presented most recently.

So the first question in the room is not build or buy. It is what this is worth if it works, and what happens if we do nothing. I have watched that question dissolve a build-versus-buy argument entirely, more than once, because the honest answer was that the feature was not worth either.

One more test, for the ones that survive

Which decision can you reverse?

Buying is usually cheaper to reverse in month three and more expensive to reverse in year three, once your data and your workflow have grown around it. Building is the opposite. If the feature is central to how your product earns money in three years, weight that. If it is a capability you expect to be free and commoditised by then, do not build a thing you will be embarrassed to still be maintaining.

What I do in practice

I write the six layers on a page. I mark each one bought, built, or undecided. Then I run the four tests on everything still undecided, and I insist that the integration cost gets written into the buy column before anyone votes.

It takes about an hour. It is faster than the comparison spreadsheet, and it produces a decision you can defend six months later, which the spreadsheet never does. That is the same instinct behind scoping to the cases that carry the volume rather than the whole surface: decide where your judgment actually lives, and spend there.