Most build-vs-buy debates die in the wrong room. They get framed as an engineering question — can we build this? — when the real question is an operating one: what does owning this cost us over three years, and who is accountable when it breaks?
I make that call for a living, and then I'm the one who ships whatever the call produces. That second part changes how I decide. When you have to live with the consequences in code, you stop romanticizing both options.
Here's the test I actually run.
1. Is this our edge, or our plumbing?
Buy your plumbing. Build your edge.
Email delivery, payments, error tracking, auth — these are solved problems with vendors whose entire business is being better at them than you will ever be. Renting that competence is the correct move, and "we could build it" is almost never a reason to.
The moment to build is when the thing is the differentiator — when an off-the-shelf tool forces your customers through someone else's idea of how the workflow should go, and that friction is the product. That's not plumbing. That's the edge, and edges should not be rented.
2. What is the contract actually indexed to?
The SaaS line item that looks cheap at signup is rarely indexed to value. It's indexed to seats, records, or events — three things that grow whether or not the tool is doing more for you.
If a vendor's price scales with your success but their value doesn't, you are financing their growth with your margin.
This is where most of the $900K I've eliminated came from. Not from heroic engineering — from noticing that a contract had quietly become a tax on scale, and that the underlying capability was a few hundred lines of code we could own outright.
3. Can a small surface replace a large one?
Vendors sell suites. You usually need a slice.
Before replacing anything, I map what we actually use against what we pay for. The honest answer is often 15%. And 15% of a bloated platform is frequently something a focused internal tool does better — because it does only that, in our language, wired to our data, with no onboarding and no per-seat ceiling.
If replacing the whole platform is a quarter of work, replacing the slice we use is often a week.
4. Who owns it at 2am?
This is the question that kills bad build decisions, and it should.
Buying means someone else carries the pager. Building means you do — the migration, the edge cases, the security posture, the boring maintenance that never makes a roadmap. If there's no honest answer to "who maintains this in eighteen months," the answer is buy, even when building is cheaper on paper.
I only green-light a build when I'm willing to be that owner. That constraint has saved me from more bad builds than any spreadsheet.
The shape of a good decision
A good build-vs-buy call usually looks like this:
- The capability is close to the edge, not the plumbing.
- The contract is indexed to scale, not value.
- We use a thin slice of a thick product.
- Someone — often me — will own it for real.
When three or four of those are true, building wins, and it isn't close. When they're not, I sign the renewal and spend the engineering somewhere it actually compounds.
The discipline isn't being able to build. It's being honest about when you should — and then being the one who ships it.
Working through a build-vs-buy decision of your own? Get in touch.