How do you decide whether to build a capability in-house or buy it?

Differentiation first, cost second

The opening question is not what it costs. It is whether a customer would ever choose you because of this capability. If the answer is no, the default is to buy, and the burden of proof sits with whoever wants to build.

A payments company builds its ledger and buys its help desk. An observability vendor builds its time-series store and buys its billing. The reason is not that ledgers are hard and help desks are easy — it is that engineering attention is the genuinely scarce resource, and every quarter spent on a capability nobody chose you for is a quarter not spent on one they did.

This ordering matters because cost arguments are slippery in both directions and differentiation is comparatively stable. Lead with cost and you will end up in a spreadsheet argument. Lead with differentiation and the spreadsheet becomes a tiebreaker rather than the decision.

Compare the right two numbers

The comparison that gets made is the vendor's annual licence against nothing, because the alternative is "we'll build it" and building feels free once the team is already on payroll. It is not free, and the honest build-side figure has four parts.

Initial development, which is the only part anyone estimates and is reliably the smallest. Maintenance for the life of the system, which for a long-lived internal tool routinely exceeds the build cost several times over. Operations — someone carries a pager for this, and the on-call load is real whether or not anyone accounts for it. And opportunity cost, the highest-value work those engineers did not do, which is usually the largest term and never appears in the comparison at all.

Run that over five years rather than one, because both options are decisions you will still be living with. A £60k annual licence looks expensive against a six-week build until the six-week build is a system that two engineers touch every quarter for five years.

The estimate itself deserves scrutiny. When a team says six weeks, they are almost always estimating the demo — the version that handles the main path for the current requirement. The product you are actually comparing against the vendor's includes the admin interface, the audit log, the migration tooling, the fourteen edge cases discovered in production and the documentation. Asking "six weeks to what, exactly?" is not cynicism, it is the question that makes the two sides of the comparison comparable.

Switching cost is the real commitment

Buying is reversible in principle and often not in practice, and the variable that decides which is where the data ends up.

A vendor that processes data you hold is a low-commitment purchase; you can replace it in a sprint. A vendor that accumulates data you cannot export in a usable form has you, and the price rises at renewal precisely because both parties know it. Data gravity, not the contract, determines your leverage.

So the questions to ask before signing are about exit rather than entry. Can you get your data out, in a documented format, including the history? What breaks if the vendor is acquired, changes its pricing model, or discontinues the product? How long would a migration take if you had to start one tomorrow? A vendor who answers those questions comfortably is telling you something; a vendor who deflects is telling you something too.

Keeping the integration behind an interface of your own is the standard mitigation, and it is worth doing where it is cheap. Be realistic about its limits, though: an abstraction over two vendors with genuinely different models tends to reduce to the intersection of both, and you end up with the features of neither plus a layer to maintain.

The answers between build and buy

Framing this as binary discards the options that most often win.

Buy and extend — take the vendor's core and build the thin layer that is actually specific to you. Adopt open source — no licence, source available, and a maintenance obligation that is smaller than building but is emphatically not zero; someone patches it, upgrades it, and debugs it at two in the morning. Buy now and revisit — the requirement is unclear, so purchase your way past the uncertainty, learn what you actually need from a year of real usage, and reconsider when the question is answerable. That last one is often the strongest answer available and is rarely offered, because it feels like indecision. It is the opposite: it is refusing to make a five-year commitment on one month of information.

Where the heuristic breaks

"Build your differentiator" fails in one important case: a capability that is core to your value but where the market has consolidated so far that building it means competing with a company that employs hundreds of specialists. Search relevance, fraud scoring, speech recognition. Here you buy the engine and differentiate in how you apply it — the data you feed it, the workflow around it, the decisions you make with its output.

The reverse case is worth naming too. A commodity capability whose integration is where your complexity lives may be worth building simply because the vendor's model does not fit the shape of your domain, and forcing the fit costs more than the thing itself would have.

The build estimate you are given is for the demo. The number you need is what it costs to own it for five years, including the work the team will not do because they are maintaining it.