Buy, build, or integrate: an AI decision framework for leaders

Every AI roadmap eventually arrives at the same three-way decision. Buy a product that already does it. Build something bespoke. Or integrate a model into a system you already own.

Most organisations answer this by instinct — engineering-led teams build, procurement-led teams buy — and then spend the next year discovering they answered it for the wrong reason. Here’s the framework we use instead.

Start with the question nobody asks

Before comparing options, establish whether this capability is differentiating or table stakes.

Differentiating means a customer would notice if you did it better than a competitor. Table stakes means they’d only notice if you did it badly. Meeting transcription is table stakes for almost everyone. How you price a complex quote might be the whole business.

The rule that follows is uncomfortable but reliable: buy table stakes, build differentiators. Teams that build commodity capability burn a year rebuilding something they could have licensed. Teams that buy their differentiator hand it to a vendor who will sell the same thing to their competitor.

When buying is right

Buy when the problem is well-defined, widely shared, and someone has already solved it properly. Transcription, document extraction, code assistance, meeting summarisation — the market is mature and your version will not be better.

Three things to check before signing:

• Where does your data go, and is it used for training? Get this in the contract, not the sales deck.
• What happens when you leave? If your data or configuration can’t come with you, the switching cost grows every month.
• Does pricing survive success? Per-seat is predictable. Per-token can be fine — model it at ten times current usage before you assume it is.

When building is right

Build when the capability depends on knowledge only you have — your data, your process, your domain — and when getting it right is worth more than getting it soon.

Be honest about the real cost. The prototype is the cheap part. What follows is evaluation, monitoring, security review, cost controls, and the ongoing work of keeping it current as models change underneath you. Building means owning that indefinitely.

The question isn’t “can we build this?” — you almost certainly can. It’s “will we still be maintaining this well in two years?”

When integrating is right — and it usually is

Integration is the option most teams underweight. You already run systems where the work happens — ServiceNow, your CRM, your data platform. Bringing a model to that work is often faster and stickier than either buying a separate product or building from nothing.

It wins on three fronts. Adoption, because nobody has to learn a new tool or change where they work. Context, because the model sits next to the data that makes its answers useful. And governance, because your existing permissions, audit trail and retention rules already apply.

A bought tool that lives outside the workflow tends to get used enthusiastically for a month and then quietly abandoned. Capability inside the tool people already open every morning doesn’t have that problem.

The decision, in four questions

Run each candidate initiative through these. The answers usually make the choice obvious.

• Would a customer notice if we did this better than a competitor? No → buy. Yes → keep going.
• Does it depend on data or process only we have? Yes → build or integrate. No → buy.
• Does the work already happen inside a system we own? Yes → integrate first.
• Can we fund the second year, not just the first? No → buy, whatever the other answers said.

That last one retires more projects than the other three combined, and it should. An unmaintained internal AI system is worse than no system — people rely on it, it drifts, and nobody owns fixing it.

Where to wait

Not everything needs a decision this quarter. Wait when the capability is improving faster than you could build it, when your data isn’t ready, or when nobody can name the metric that would move.

Waiting deliberately — with a written trigger for revisiting — is a legitimate answer. Waiting by not deciding is how roadmaps fill with pilots that never ship.

Buy your table stakes. Build your differentiators. Integrate everything in between — which is most of it.

The framework won’t make the decision for you, but it will surface the assumption you were making without noticing. In our experience that’s where these choices actually go wrong — not in the analysis, but in the question nobody thought to ask.

If you’re working through this on a live roadmap, start a conversation. You’ll be talking to the people who do the work.