Fully-Loaded Comparison

Build-versus-buy and managed-versus-self-managed decisions are routinely made by comparing the numbers that are easy to obtain: a licence price against an infrastructure estimate. Those numbers are real and they are a minority of the cost.

A fully-loaded comparison includes engineering time to build or operate, on-call burden, upgrade and migration effort, capacity planning, incident response, training, and the opportunity cost of the work not done instead.

Why it matters

The omitted terms usually favour the option that looks more expensive. A managed service at several thousand per month compares badly against self-hosting until the half-engineer of continuous operational attention is included, at which point the comparison inverts — and that half-engineer is invisible because it is distributed across a team's ordinary weeks rather than appearing on an invoice.

The same asymmetry distorts build-versus-buy. Build estimates are wrong by the largest margin in the years after version one — the maintenance, the edge cases, the compliance changes, the feature requests — and those years are exactly what a first-version estimate omits.

The result is a systematic bias toward building and toward self-hosting, made by comparing a complete cost against a partial one.

Implementation patterns

• Include engineer time at a loaded rate, and be honest about the fraction. "Half a day a week" across a team of six is a meaningful annual figure.
• Model over a realistic horizon — three to five years — including licence growth as usage scales, which for per-seat or per-transaction pricing can be dramatic. Model the price at 5× current usage, because that is where a bought solution frequently becomes the expensive option.
• Include the on-call burden explicitly, since it has a retention cost that does not appear in any budget.
• Include the crossover point in both directions: at what scale does self-hosting become economical, and is that scale plausible.
• Include exit cost — can the data be extracted in a usable form, and what would migration require. Assess this before signing, which almost nobody does.
• Include the opportunity cost: what the team would have built instead, which for a product team is usually the largest term and the one never written down.
• Include the cost of the understanding you still need. A managed service removes toil, not comprehension — the data model, capacity, failure modes and cost drivers must still be understood, and a team that assumes otherwise will misuse it.

Industry example

The reasoning drives most platform-team decisions at scale and shows up in both directions. Organisations adopting managed databases, brokers and search services do so because the fully-loaded comparison favours them until the crossover, which many never reach.

The reverse case is equally instructive: PlanetScale's decision to discontinue its free tier turned on exactly this analysis from the provider's side — per-tenant infrastructure floors, control-plane overhead, fleet engineering that scales with instance count rather than instance size, and support burden that does not fall with tenant size, none of which appear in a naive marginal-cost model.

Failure scenarios

• Comparing licence cost against infrastructure cost only, which is the default and is wrong.
• Excluding engineer time, on the reasoning that the team is already paid.
• A three-month build estimate with no maintenance projection.
• Ignoring licence scaling, so a per-seat product becomes the largest line item after growth.
• Exit cost unassessed until the day someone wants to leave.
• Opportunity cost omitted, which is the largest term for a product team.
• Assuming a managed service requires no expertise, then misusing it and attributing the result to the service.
• Precision theatre — an elaborate model whose inputs are guesses, presented with false confidence.

Trade-offs

A fully-loaded comparison takes real effort and its inputs are uncertain. Engineer time estimates are approximate, opportunity cost is genuinely unknowable, and a model built on those inputs should not be presented as precise.

It can also be used to justify a predetermined conclusion, since the assumptions carry the result — which is an argument for stating them explicitly and testing the conclusion's sensitivity to each, rather than for avoiding the exercise.

The trade is analytical effort and unavoidable uncertainty against a decision made on a systematically incomplete picture. The exercise is worth doing not because the number is right but because it surfaces the terms that were about to be ignored — and in most cases identifying the omitted terms changes the decision without the arithmetic needing to be exact.

Interview question

"Self-hosting this would cost us £4,000 a month in infrastructure and the managed version is £11,000. Walk me through what else belongs in that comparison, tell me roughly what you would expect each term to be worth, and tell me at what scale the answer flips."