Build-versus-buy arguments run long because they are usually conducted as a debate about capability. They resolve quickly when reframed as four factual questions.

1. Is this a differentiator or a utility?

If a customer would notice and care that your version is better, it may be worth building. If it is table stakes — document extraction, transcription, standard classification — you are buying a commodity and should buy it.

Be honest here. Most organisations overestimate how much of their stack is differentiating. The test is whether you could describe the advantage to a customer in one sentence they would find compelling.

2. Do you have proprietary data that changes the answer?

This is the strongest argument for building. If you hold twenty years of labelled failure data specific to your equipment, a vendor's general model cannot match a model trained on it. That advantage is real and durable.

If your data is broadly similar to everyone else's in the sector, the vendor has more of it than you do, and building means starting behind.

Proprietary data is the only build argument that gets stronger over time. Every other advantage erodes as vendors improve.

3. Can you staff it for five years, not five months?

Building is not a project cost, it is an operating commitment. Models drift, dependencies age, the person who wrote it leaves. If you cannot name who maintains this in year three, you are not building — you are creating future technical debt with a launch party.

4. What does being six months late cost you?

If the answer is "very little", building may be reasonable. If a regulatory deadline or a competitive window is involved, buy now and revisit later. Buying is reversible far more often than teams assume, particularly if you keep your data and your evaluation harness under your own control.

The pattern that usually wins

Buy the commodity layer, build the thin differentiating layer on top, and own the evaluation harness and the data regardless of which way you go. That combination keeps the switching cost low and the advantage where it belongs.

Scoring it

Answer all four in a single session with the people who own the budget and the roadmap. Two or more answers favouring buy usually settles it, and the meeting takes an afternoon rather than a quarter.

The framework's real value is not the answer — it is that it makes the disagreement specific. When people argue about build-versus-buy in the abstract they are usually disagreeing about question one or question three without realising it.