Build-vs-buy is a bet on which doors stay open.

Build-vs-buy almost always shows up as a spreadsheet. License cost here, engineering cost there, a line for maintenance, a fudge factor, a total. Whichever column is smaller wins. It feels rigorous. It’s usually the wrong question.

The spreadsheet answers what’s cheaper this year. The decision you’re actually making is which doors you’re willing to close. Building something is close to a one-way door: the real cost isn’t the first version, it’s the maintenance tail, the context that lives only in your team’s heads, the fact that it’s now yours forever. Buying is usually a two-way door — until it isn’t. The moment your data, your workflows, and your integrations grow roots into a vendor, the rented thing quietly becomes a thing you can’t leave. You bought a two-way door and woke up on the one-way side.

So run the decision on two axes instead of one. First: how core is this? Is it the thing you’re differentiated on — the reason a user picks you — or is it plumbing that every company in your category has? Second: how reversible is the choice? Not the price of switching today, but how one-way the door really is once you’ve committed: the lock-in, the switching cost, the migration you’d have to live through.

Those two axes give you four very different bets.

Core, and hard to reverse → build. This is the only quadrant where building is obviously right. It’s the thing you win on, and you’re going to be stuck with your choice either way — so own it, control it, make it the one that can’t be bought off a shelf. Reserve your scarce building capacity here. If everything feels like it belongs in this box, you haven’t been honest about what’s actually core.

Commodity, and easy to reverse → buy, cheerfully. Auth, payments, email delivery, error tracking. Buy it, don’t fall in love with it, stay ready to swap it. Building here is how teams bleed out — a hundred little in-house tools, each a small genius idea, each now a maintenance obligation nobody remembers signing up for.

Commodity, but hard to reverse → the trap. This is the quadrant to fear. It’s not core, so building it is a waste — but the switching cost is high, so a careless buy locks you into a vendor for something you don’t even care about. Here the work is to lower the reversibility cost before you commit: abstract behind your own interface, keep an export path, refuse the deepest integration. Make the door two-way again, then buy.

Core, but easy to reverse → start by buying, plan to own. The thing matters, but you can switch cheaply for now. Rent it to learn what “good” even means while the stakes are low, and keep the option to build later open. Buying here buys you time and information, not a permanent answer.

Notice what drops out: this is the same muscle as judging a decision by how one-way its door is, just pointed at a specific recurring choice. The cost comparison still matters — it just isn’t the axis. It’s a tiebreaker inside a quadrant, not the thing that picks the quadrant.

The teams that get this wrong rarely do so because they ran the numbers badly. They do it because they built the thing that was cheap to buy and reversible — their own half-maintained version of a solved problem — and bought the thing that was core and would’ve been worth owning. They optimized the spreadsheet and lost the doors.