Build-Versus-Buy Crossover Point

An infrastructure bill crosses a number that makes someone uncomfortable, and a proposal appears to bring the workload in-house. The proposal compares the vendor's annual invoice against the cost of a migration project. That comparison is always favourable and almost always wrong, because the migration ends and the operation does not.

The crossover is not a single number. It is a conjunction, and a proposal that satisfies three of four conditions is a proposal to lose money slowly.

Why it matters

The asymmetry is what people miss. A vendor's exit cost is paid once; self-operation is paid every year, forever, and it grows with headcount inflation rather than with technology getting cheaper. So a decision justified on a one-off comparison is being justified on the wrong axis.

The second reason is that the transferred risk is rarely priced. When you buy managed storage you are buying a durability guarantee. Bring it in-house and you are now the party that loses customer data if the erasure coding, the repair pipeline or the capacity forecast is wrong. That liability does not appear on either side of the spreadsheet, and it is frequently the largest term.

Implementation patterns

The four conditions, all of which must hold:

• The workload is the product's core cost driver. If it is not, you are optimising a line item that cannot move the P&L even if you eliminate it entirely.
• Scale is large enough that a few percent of unit cost exceeds the standing cost of the team. A four-engineer team is roughly $1M a year in 2026 terms; the saving must clear that with margin before the trade is positive.
• The access pattern is narrow and stable. A general-purpose managed service wins whenever the pattern is still changing, because its generality is exactly what you would otherwise have to build.
• You can fund a decade of operation, not a migration. On-call, hardware refresh, capacity forecasting and the slow accumulation of operational knowledge are the commitment.

Two supporting practices: price against your negotiated rate, not list price, and model the saving as a percentage of a line that scales, so you can see whether it survives growth.

Industry example

Dropbox moved file storage off Amazon S3 onto Magic Pocket, its own infrastructure, completing the migration in 2016. All four conditions held: storage is the product, so a stored byte is cost of goods sold rather than overhead; the scale was large enough that a few points of unit cost were worth more than the team; the access pattern was narrow and well understood after years of operating it; and the company could fund a permanent storage organisation.

Move the same reasoning to a company where storage is 4% of spend and the arithmetic inverts completely: the team costs more than the entire possible saving, every year, and the durability risk arrives for free.

Failure scenarios

• Comparing invoice against project cost, so the standing operational cost never enters the decision.
• Lock-in anxiety as the motivation. A real concern, but it is a reason to keep an exit path cheap, not a reason to insource - exit cost is paid once.
• Underestimating durability engineering. Storing bytes is easy; proving they are still there, repairing silent corruption, and surviving correlated hardware failure is the actual work.
• Losing the option to grow. Hardware has a months-long lead time. A forecast miss that a vendor absorbs with an API call becomes a capacity freeze.
• The talent tax. The strongest infrastructure engineers move onto the in-house system and off product work, and that cost shows up two years later as a shipping slowdown nobody attributes to the decision.
• Reversing it is far harder than making it. Once data lives on your own hardware, moving back is a second migration with a second risk profile.

Trade-offs

When not to use it

When the capability is not what the business sells. Identity, email delivery, payments, observability storage and queueing are bought by almost everyone above almost any scale, because none of them is the product and all of them are deep.

Also when growth is still uncertain: self-operation converts a variable cost into a fixed one, which is the wrong direction when the forecast is wide. And when the team you would need does not exist in the company and cannot be hired in the relevant market - a plan that depends on hiring six specialists is a plan with a hiring risk, not an engineering one.

Interview question

Q: Your cloud observability bill is $4M a year and growing faster than revenue. An engineer proposes running the open-source stack in-house and estimates a six-month project saving 60%. Walk me through how you would evaluate that, and what would make you say yes.

What a strong answer covers: replacing "project cost versus invoice" with "standing cost versus recurring saving", including the on-call rotation and the storage engineering · testing the four conditions explicitly, and noticing that observability is usually not the product's cost driver even at $4M · that the first move is almost always to reduce the bill rather than to move it - cardinality, retention tiers, sampling, and renegotiation frequently take 40-60% out without changing vendor · the durability and availability obligation transfer, including the circular dependency of running your own monitoring on your own platform · and a reversibility plan if the in-house system underdelivers.

Quick check

Quiz: A proposal compares the vendor's annual invoice against the cost of a migration project. What is wrong with the comparison? The migration ends and the operation does not - the correct comparison is the recurring saving against the permanent cost of the team, capital and risk that self-operation adds.

Flashcard: Is lock-in anxiety a crossover condition? — No. Exit cost is paid once; self-operation is paid annually. Lock-in is a reason to keep the exit path cheap, not a reason to insource.