Build vs buy is four decisions, not one

The build-versus-buy conversation usually happens with one number on the whiteboard: what it would cost to build. Sometimes there's a second: the vendor's annual licence. Comparing those two figures is comparing a one-off with a recurring cost, and it tells you almost nothing. The comparison that matters has four columns.

Build cost

Cost to create. The estimate everyone argues about, and the one that matters least over a five-year horizon. It includes people, tooling, licences and the part usually left out: the opportunity cost of the team while it is building this instead of something else.

Run cost

Cost to operate. Cloud, inference, support, on-call, patching, monitoring, the person who understands it. For a bought product this is largely the subscription plus integration upkeep. For a built one it is a permanent line in the engineering budget that is easy to underestimate because it arrives in small pieces.

Change cost

Cost to evolve. This is where the comparison flips. A built system changes at the speed of your team, in the direction you need. A bought one changes at the vendor's roadmap speed, in the vendor's direction, and every customisation you add is a change you now own on top of theirs. Ask: what happens the first time we need something the product doesn't do?

Exit cost

Cost to replace or leave. The one nobody costs at the start because nobody plans to leave. Data export in a usable form, contract minimum terms, the parts of your process that quietly reshaped themselves around the product, the retraining. This is the reversibility question in monetary form, and it is frequently the deciding factor when it is actually calculated.

The option that wins on build cost usually loses on at least one of the others. That's not a reason not to choose it. It's a reason to know.

Hybrid is not a compromise, it's a boundary decision

Most real answers are hybrid: buy the commodity, build the differentiator. The hard part is drawing the line. A useful test is to ask which parts of the system a competitor could not buy. Those are the parts worth building. Everything else is a candidate for a product, a managed service, or an open-source component that someone else maintains.

• Buy: authentication, payments, email delivery, observability, the vector database.
• Build: the workflow that encodes how your organisation actually makes its decisions; the evaluation set that defines “correct” for your domain.
• Decide deliberately: the orchestration layer between them, where lock-in accumulates.

None of this produces a number you can put in a slide without assumptions. It produces a table with four columns and a confidence label on every cell, which is a far better basis for a decision than one number with false precision.