A CTO I advised last year spent nine months and roughly $400K building a custom billing engine. Six weeks after launch, Stripe shipped the exact feature they'd hand-rolled — usage-based metering with proration — as a config toggle. The engine still works. But now two engineers babysit it forever, and every pricing experiment routes through a queue only they understand. That's the real cost of a build-vs-buy decision that didn't age well: not the wasted quarter, but the permanent tax you pay afterward.
Most of these decisions get made in a single meeting, on gut and org politics. They deserve better, because you rarely get to revisit them cleanly.
The question isn't "can we build it?" — it's "should we own it?"
Any competent team can build almost anything. That's exactly why "can we?" is the wrong question. The real question is whether this capability is worth owning — carrying its maintenance, on-call, security patching, and opportunity cost for years.
I use one filter before anything else: is this core or context? Core is the thing customers pay you for, the part where being different is the whole point. Context is everything else that merely has to work — auth, billing, log shipping, feature flags, email delivery. You should build the 10–20% that is your product, and buy the 80% that isn't, even when you could build it better on a whiteboard.
If a vendor outage would embarrass you but not end you, that's context. If you'd want it patented, it's core.
Buying has a bill that arrives late
Teams underprice building because the invoice is a salary they're already paying. They overprice buying because the vendor's number is right there on the page. Both instincts are wrong, and the correction runs in both directions.
The honest cost of building isn't the first version — it's the total cost of ownership over three years:
- The 40% you forgot: admin UI, audit logs, rate limiting, the second region, GDPR deletion, the migration when your assumptions change.
- The bus factor: the two people who understand it become unpromotable and unquittable.
- Opportunity cost: every sprint on undifferentiated plumbing is a sprint not spent on the thing only you can build.
Buying has its own late bill: per-seat pricing that scales with your success, the integration that's never quite done, and lock-in that quietly sets a ceiling on what you can change. A tool that's cheap at 20 people can be a hostage negotiation at 2,000. Price the exit before you sign the entry.
Design for the reversal, because you'll be wrong sometimes
You won't get every call right, so the smart move is making each one cheap to undo. The decisions that age well aren't the ones that were correct forever — they're the ones you could walk back without a rewrite.
Wrap what you buy
Never let a vendor's SDK spread across your codebase. Put it behind your own interface — a thin adapter your app talks to instead. When you swap Twilio for Vonage, or your homegrown search for a hosted one, you change one module, not two hundred call sites. This one habit converts most "irreversible" platform bets into a weekend.
Prefer boring, standard, and portable
- Own your data even when you rent the compute — export paths and standard formats over proprietary stores you can't leave.
- Pick the technology with the deepest hiring pool, not the cleverest benchmark. You're buying a decade of maintainers.
- Be suspicious of anything that needs a conference talk to justify. Novelty is a liability you pay for in 3 a.m. pages.
A test you can run Monday
Next time this comes up, before the debate starts, force four answers onto one page:
- Core or context? If context, the default is buy — you need a real reason to override it.
- Three-year TCO, both paths. Include the maintenance, the people, and the exit — not just the license or the first sprint.
- What's the reversal cost? If ripping it out later means a rewrite, buy time by wrapping it now.
- Who owns it at 3 a.m.? If you can't name the on-call owner for the next two years, you're not ready to build it.
The best builders I know are ruthless about how little they build. They spend their scarcest resource — senior engineering attention — only where owning the thing is the advantage, and rent the rest without ego. Buy your plumbing, build your edge, and wrap everything so tomorrow's you can change today's mind.
Look at your current roadmap: which build is really context in disguise — and what would you ship instead if you bought it?