Build vs Buy Is an Ownership Decision, Not a Cost Decision

Build versus buy arrives as a finance question and gets decided in a room full of engineers. Somebody puts two columns on a slide. One column has a vendor's annual figure. The other has a headcount estimate multiplied by a loaded cost per engineer. Whichever column is smaller wins, with a hedge about strategic fit at the bottom of the slide that nobody reads aloud.

I have sat on both sides of that slide across content, data and seller experience, payments, connected devices, enterprise applications, an early-stage e-pharmacy and wealth management. The decisions that aged badly were almost never the ones where somebody got the arithmetic wrong. They were the ones where the arithmetic was the whole conversation.

The spreadsheet answers a question nobody asked

The two-column slide compares the price of acquiring a capability. That is a real question, and it is not the question the organization is actually deciding. The organization is deciding who carries this thing for the next five years, who gets paged about it, whose roadmap has to bend when it needs to change, and what happens on the day it no longer fits.

Cost models are seductive because they produce a number, and a number feels like a decision. But the number covers the shortest and least interesting part of the system's life. Acquisition is a quarter or two. Ownership is the rest of it.

Ownership is the thing actually being traded

Here is the trade, stated plainly. When you build, you own the implementation and the roadmap, and you pay for both forever. When you buy, you trade the implementation and the roadmap for a dependency, and you pay for that forever instead. Neither option is ownership free. They are different ownership, with different levers and different failure modes.

The vendor pitch blurs this on purpose, and I do not say that cynically. It is an honest description of what the vendor is selling: the capability, ready, without the build. What the pitch cannot include is the part that stays yours no matter what you sign.

You cannot outsource ownership of an outcome your customers hold you responsible for. You can only outsource the levers you would have used to fix it.

What stays yours either way

The outcome your customers see

When the bought component degrades, your users do not experience a vendor incident. They experience your product failing. Your on-call engineer gets the page, your support team absorbs the volume, and your executive writes the note. The escalation path now runs through somebody else's support queue, on somebody else's severity scale, at somebody else's pace. That is not less ownership. That is the same ownership with a longer wire.

The integration

Nothing bought arrives finished. It arrives needing identity, data mapping, error handling, observability, an access model and a place in your deployment story. That glue is code you wrote, that only you maintain, and that no cost model counts because it was not in either column. It is frequently the part that ages worst, because it belongs to no team's charter and shows up in no roadmap.

The exit

Every bought capability eventually ends: the vendor is acquired, the pricing model changes, the product is sunset, or your needs move somewhere the roadmap will not follow. The exit is yours, in full. It is also the single cost most consistently left out of the original decision, which is why it tends to land as a surprise on a team that did not make the call.

Total cost of divergence

If you want one number to replace the two columns, make it this one: what does it cost you the day your requirements and the vendor's roadmap point in different directions?

That day is not a risk. It is a certainty, because the vendor is optimizing for the middle of their market and you are optimizing for your own. Divergence is the normal end state of a healthy vendor relationship, not a failure of it.

So ask what happens when it arrives. Can you extend around the gap, or does the product's shape forbid it? Are you one customer among thousands asking, or are you large enough that your ask becomes their roadmap? If neither, what does building the missing piece yourself cost, on top of what you are already paying? Those questions have real answers, and the answers separate a boring dependency from an expensive one far better than the license figure does.

The two questions that actually decide it

1. Is this core?

Core does not mean hard, and it does not mean interesting to engineers. It means a customer would notice, and care, if you were merely average at it. Most infrastructure is not core by that test. Authentication is rarely core. Billing plumbing is rarely core. The thing your product is actually better at than the alternatives is core, and it is usually narrower than the team wants it to be.

Building non-core capability is the most common expensive mistake I have watched teams make, and it never looks like a mistake at the time. It looks like a team with real skill solving a real problem well. The same trap the platform team trap describes applies here: capability you can build is not the same as capability you should own.

2. What does leaving cost?

Exit cost is the honest measure of a dependency. Ask it before signing, in concrete terms: if this vendor doubled its price or announced a sunset next quarter, what would we actually do? If the answer is a migration with a known shape and a bounded cost, buy without much anxiety. If the answer is that our data model would have to be rebuilt, or that nobody here knows how the thing works, you are not buying a component. You are buying a future project you have not scoped.

Put the two together and the map is simple. Non-core with a cheap exit is a buy, and you should stop debating it. Core with an expensive exit is where building earns its keep. Non-core with an expensive exit is the quadrant worth real work, because it is where you should buy but negotiate hard for portability. Core with a cheap exit is the pleasant case: buy now, build later if it ever matters, and you have lost nothing.

The decision that was never written down

One more failure mode, and it is the quiet one. Most build versus buy decisions are never made. They are drifted into. An engineer needs something on a Thursday, picks a tool, wires it in, and three years later it is load bearing and nobody remembers choosing it. No slide, no two columns, no exit cost, just a dependency that grew teeth.

The fix is unglamorous: write the decision down when it is small. One paragraph naming what you chose, why, what it would cost to leave, and who owns the integration. It takes twenty minutes and it is the difference between a dependency you manage and a dependency that manages you. It also turns into the evidence you need later, when someone asks why the architecture looks the way it does.

None of this makes buying the wrong answer. Buying is usually the right answer, and teams that build everything are not disciplined, they are just slow. The point is narrower than that: you are not choosing between paying and not paying. You are choosing which ownership you keep and which levers you give up to keep it, and that is a decision worth making on purpose, in the open, with the exit written down while it is still cheap.

Haseeb Afsar