Build or buy: how I decide on an AI feature

Somebody demos a tool, somebody else says we could build that, and then two weeks go into a comparison spreadsheet that answers a question nobody should have asked.

Build-versus-buy isn’t 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’s 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’re 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’ll fill yourself. That’s fine, and it’s often the right move, but price it honestly. You’re 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’re going to own that failure whoever built the thing. Owning a failure you can’t 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 can’t measure whether it works on your cases, you’ve not bought a feature, you’ve 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’s the expensive one. Buying doesn’t 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 can’t 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’s a team of three maintaining an integration layer that’s larger than the feature would have been.

I don’t think this is avoidable by being cleverer about vendor selection. I think it’s 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 an estimate everyone has agreed not to look at.

Sizing, and why most teams can’t run these tests at all

None of the above helps if nobody has sized the value. BCG’s July 2026 survey of 152 chief executives 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.

So the first question in the room isn’t build or buy. It’s what this is worth if it works, and what happens if we do nothing. I’ve 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. That’s the same failure I wrote about when coverage gets mistaken for value.

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’s a capability you expect to be free and commoditised by then, don’t build a thing you’ll 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’s faster than the comparison spreadsheet, and it produces a decision you can defend six months later, which the spreadsheet never does.