Build, Buy, or Partner: How to Decide

Almost no AI buying committee asks the right question. It asks the price. It should ask how long the edge it's signing for will last.

Carlos Andrés Ramírez · 2026-09-01

A CTO told me recently he had compared three proposals to automate contract review for his legal team. The three price tags were close enough not to matter. None of the three proposals said what the company would keep if it ever wanted to switch vendors. He signed with the one that gave the best demo.

That pattern repeats in almost every committee that decides between buying and building AI: the axis that decides is price, and price is the easiest question to answer and the least important one. It tells you what is cheapest to sign this quarter. It says nothing about what happens to that edge in three years, once the same platform gets sold to your closest competitor too.

There is a third option that almost never makes the shortlist. Building with a partner, sharing the development and the risk instead of buying it finished or building it alone, rarely comes up because nobody in the room has an incentive to propose it. The vendor selling software wants you to buy. The firm billing by the hour wants you to build. Nobody sells the third option, so nobody raises it.

The symptom

How do you decide what to buy and what to build in AI?

It gets decided badly whenever the criterion is written after the proposals arrive instead of before, which is most of the time. The committee looks at three offers, compares price and time to launch, and picks. The question underneath, whether this capability is something the company needs to control to keep competing three years out, never shows up as a row on the comparison sheet.

• The comparison sheet has columns for price and timeline, and none for what the company keeps once the contract ends.
• The business function that owns the process isn't in the room where the decision gets signed, only technology and procurement are.
• Nobody has modelled what happens if the vendor raises the price next year, changes ownership, or shuts down.
• Building with a partner never made the shortlist; only two finished-product offers got compared.
• The company defaults to building what is actually a standard capability anyone can buy, and to buying what is actually its differentiator.
• The criterion used to decide gets written to justify the proposal people already liked, not before reading any of them.

The problem underneath

Price decides an axis that was never about price.

Price compares what's comparable: two numbers in the same currency, easy to put side by side on a slide. That's why it wins the argument, even when it isn't the question that actually needs answering. The real question has four parts, and none of them show up in a commercial proposal: whether the capability is part of how the company competes or a standard one anyone can match, how long the edge lasts before the market catches up, what data the value actually depends on, and who sustains the system the day after it launches.

Buying is fast and it moves the technical risk onto someone else. It also moves the edge. Buy it on a platform that sells the same thing to your competitor, and you haven't bought an edge, you've bought parity with a head start. Building gives control and, if the data is proprietary, a real edge. It also demands a team to sustain it after launch, and that team doesn't appear on its own just because the model worked in the demo.

Buying someone else's AI is renting their edge. Building your own is a bet that you'll know how to sustain it. Both are legitimate calls. Signing without knowing which one you made is not.

BECOME

The framework

What to check before signing anything.

Order matters here. The five questions below get answered before asking anyone for a proposal, not after comparing them. Asked afterwards, every vendor answers them in their own favour.

Core

Whether the capability is part of how the company competes, or a standard one any competitor can match. The first gets built, or co-built with a partner. The second gets bought, the sooner the better.

Half-life

How long the edge lasts before it becomes the market standard. If the answer is measured in months, building it never pays back the time it took to stand up.

Proprietary data

Whether the value comes from data only the company holds, or from a generic model wrapped in a well-written prompt. Without proprietary data there's no edge to defend, bought or built.

Capacity to sustain it

Whether the team that retrains, monitors and fixes the system the day after launch already exists, or is being hired. Building without that capacity manufactures next year's stalled pilot.

Exit clause

What the company keeps if the relationship with the vendor or the partner ends: the model, the data, the code, or just the memory of having used it. Negotiated before signing, never after.

The third option, building with a partner, tends to win whenever the capability is a true differentiator and the company doesn't yet have the team to sustain it alone. It splits the build risk, and if the contract is written properly, it transfers real capability to the internal team over time instead of leaving it permanently dependent on whoever built it. The reason it rarely gets proposed isn't that it performs worse. It's that nobody in the room sells it.

Take the next buy-or-build decision sitting on your desk and answer the five questions before looking at a single proposal. If the business function that owns the process can't answer at least three of them, the decision isn't ready for committee yet, no matter how many proposals are already on the table.

Let's work out your build-or-buy call