Build vs. buy: a framework, not a feeling

Most build-vs-buy conversations happen backwards. Someone proposes a tool, someone else says "we could just build that," and the room picks a side before anyone has written down what the decision actually depends on. Six months later, whichever side won is quietly relitigating it.

Here's the version that holds up: build-vs-buy isn't one decision, it's three, and they have different answers.

1. Is this differentiating, or is it plumbing?

If a capability is part of why customers pick you, own it. If it's undifferentiated infrastructure — auth, billing, observability, queueing — a vendor has already spent more engineering time on it than you ever will, and every hour your team spends on it is an hour not spent on the thing that's actually yours. This is the filter that kills most "let's build it" proposals before the next two questions even matter.

2. What's the real total cost, not just the sticker price?

The vendor's invoice is the easy number. The real comparison includes:

• Integration cost — not just the initial build, but every place the vendor's model doesn't quite match yours, and the workaround code that accumulates around those seams.
• Operational cost — who's paged when it breaks at 2am, and whether that's now your team's problem or someone else's SLA.
• Opportunity cost — the feature your team didn't ship because they were maintaining an in-house version of something a $200/month SaaS product does better.

Building almost always looks cheaper in the estimate and more expensive eighteen months in, because the estimate only ever prices the first bullet.

3. What does it cost to change your mind?

This is the one people skip, and it's the one that actually predicts regret. A vendor decision is usually reversible — painful, but reversible, because the interface between "your system" and "their system" is a contract you can renegotiate or replace. A build decision embeds itself in your codebase, your data model, and your team's mental model of how the system works. Undoing a bad build decision means someone has to understand it well enough to unwind it, which is a much higher bar than understanding it well enough to have built it.

So the honest question isn't "which costs less right now" — it's "if this turns out to be wrong, which mistake is cheaper to walk back." Buy decisions fail cheap. Build decisions fail expensive, slowly, in a way that's hard to notice until it's load-bearing.

Where this actually gets used

In practice, this framework mostly does one job: it gives a room permission to say "this is plumbing, we're not writing our own version of it" without that sounding like giving up. That single sentence, said early, is worth more engineering time than almost any other decision a technical leader makes in a quarter.