Build vs Buy: The Question Companies Get Wrong

"We can build that in a weekend."

I've heard that sentence right before some of the most expensive decisions I've watched companies make. The build vs buy question looks simple from the engineering side, because engineers are, correctly, confident they can build things. The problem is that "can we build it" is almost never the right question. "Should we own this forever" is.

Let me give you the framework I actually use, because most build vs buy advice online is either a vague pros-and-cons list or a vendor trying to sell you the "buy" side.

The cost you're comparing isn't the cost you think

When teams weigh building against buying, they compare the vendor's annual price against the engineering time to build the thing. That comparison is wrong in a way that costs real money.

The vendor price is the full cost of buying. The build cost is not the cost of building. It's the cost of building, plus maintaining, plus the security patches, plus the on-call burden, plus the feature requests that never stop, plus the institutional knowledge that walks out the door when the engineer who built it leaves. Software you build isn't a purchase. It's a puppy. The adoption fee was never the expensive part.

I've watched a company "save" $40k a year by building their own internal auth system, then spend three engineers' worth of attention on it for the next two years. That's not a saving. That's a $600k feature they gave themselves, plus a security surface they now own personally.

The one question that sorts most of it

Here's the test that resolves maybe 80% of build vs buy decisions in one move:

Is this thing core to why customers pay you, or is it plumbing?

If it's the thing that makes you different, your matching algorithm, your pricing engine, the workflow that is your actual product, build it. Owning it is the point. Every hour spent there compounds into your moat.

If it's plumbing, auth, billing, email delivery, analytics, error tracking, the CRM, buy it. Not because you couldn't build it, but because building it wins you nothing. Nobody has ever churned because your internally-built logging was slightly more elegant than a bought one. They churn because the core product was weak while you were busy polishing the plumbing.

Simon Wardley has a mapping technique for exactly this, and I built a primer on it because it draws the line beautifully: the more commodity and well-understood something is, the more building it yourself is just re-manufacturing a thing you could rent. You don't run your own power station. You plug into the grid and spend your genius on your actual business.

When "buy" is the trap instead

To be fair to the other side, buying has its own failure mode, and it's worth naming so this doesn't read like a sales pitch for SaaS.

You can buy your way into a Frankenstein. Fifteen tools that each solve one problem, none of which talk to each other, and now you've got an integration tax that quietly exceeds what building a focused internal tool would have cost. The "buy everything" reflex can be just as lazy as the "build everything" one.

The other trap is buying something core because it's faster today, and waking up in two years unable to differentiate because the thing that should have been your edge is a config screen in someone else's product. If a vendor owns your core, they own your ceiling.

So the buy decision has its own follow-up question: if this vendor doubled their price or got acquired by a competitor, how badly would it hurt? For plumbing, the answer is "annoying, we'd switch." For anything core, the answer is "a lot," and that's your signal to think harder about ownership.

A quick decision checklist

Run any candidate through these. Most decisions fall out cleanly.

1. Is it core or plumbing? Core leans build, plumbing leans buy.
2. How well-understood is the problem? Mature, commoditized problems have good products already. Novel problems don't, which is often why they're worth building.
3. What's the total cost of owning it for three years? Not the build cost. The owning cost. Be honest about maintenance and on-call.
4. What's the switching cost if we're wrong? High switching cost means slow down and think, whichever way you're leaning.
5. Does building it teach us something that compounds? Sometimes building a thing is how your team learns a capability you'll need later. That's a real, if soft, reason to build.

None of these is a formula that spits out an answer. They're a way to make the trade-offs visible so the loudest person in the room doesn't win by default.

The honest summary

Build the things that make you special. Buy the things that make you normal. And when someone says "we can build that in a weekend," gently ask them who's maintaining it in three years, because that person is the real price tag.

---

Facing a build vs buy call that could shape your architecture and your budget for years? A second opinion is cheap compared to the wrong decision. I do technology consulting on exactly these. Reach out.