I've watched companies spend two years and millions building something they could have bought for £50k per year. I've also watched companies buy solutions that locked them into a vendor forever and cost more than building would have.

The build vs buy decision is one of the most consequential choices in technology leadership. And it's almost never made rationally.

Why engineers want to build

Let's start with honesty about incentives.

Engineers want to build things. It's more interesting than integrating someone else's product. It looks better on a CV. It's more fun.

"We have unique requirements" is often true and almost always overstated. Yes, every business has some unique aspects. No, most of them don't actually require custom software.

The technical challenge is seductive. "We could build a better version" is a statement that's technically true and strategically irrelevant. You're not in the business of building better versions of commodity infrastructure. You're in the business of whatever your actual business is.

Why executives want to buy

The other side has its own biases.

Executives see a product demo and think "done." They don't see the integration work, the customisation, the ongoing maintenance, the vendor relationship management.

"We'll just buy something" feels like it removes risk. It doesn't. It changes the risk profile. Now you're dependent on a vendor's roadmap, their security practices, their continued existence.

The total cost of ownership for bought solutions is routinely underestimated by 50-100%. The licence fee is just the beginning.

The framework I actually use

When clients ask me to evaluate build vs buy, I focus on a few key questions:

Is this your competitive advantage?

If the thing you're building is what makes you different from competitors, build it. If it's commodity infrastructure that every company needs, buy it.

A fintech's core pricing algorithm? Build it. The same fintech's transactional email infrastructure? Buy it.

What's the true cost to build?

Not the estimate from the team that wants to build it. The realistic cost including development time (multiply initial estimates by 3), opportunity cost of not working on other things, ongoing maintenance (roughly 20% of build cost per year), and the risk that you build the wrong thing.

What's the true cost to buy?

Not just the licence fee. The realistic cost including integration and customisation, training and change management, ongoing vendor management, and the cost of being locked in if the vendor raises prices or gets acquired.

What's the switching cost?

Both options create switching costs. Building creates technical debt and institutional knowledge that's hard to replace. Buying creates vendor dependency and data portability challenges.

The question is which switching cost you're more comfortable with.

How certain are your requirements?

If you know exactly what you need and it won't change, buying makes sense. Vendors have optimised for known patterns.

If you're still figuring things out, building gives you flexibility. Custom code can evolve with your understanding.

The hidden third option

Most build vs buy discussions miss the actual best answer: buy and extend. Or leverage mature open source where it exists. Don't reinvent the wheel when someone's already built it and given it away.

Now if I were a salesperson, this is where I'd tell you about AxisOps' Microcelium. But I'm not, and I won't. The point is to stay impartial.

Start with a commercial product for the 80% of functionality that's commodity. Build the 20% that's genuinely unique to your business on top.

This is harder than it sounds. It requires: - Choosing products with good APIs and extension points - Accepting that you won't control everything - Resisting the urge to rebuild the parts you bought

But it's often the right answer. You get speed to market from the bought components and differentiation from the built components.

The AI wildcard

Well done for reading this far. Now here's where the plot twists.

Everything I've said above is still correct. These frameworks have served technology leaders well for decades. But as of mid-2025, vibe coding has torn through the build vs buy debate like a toddler through a Jenga tower.

Now Dave from accounts can spend an afternoon (and a late evening debugging) and rock up with something that does 80% of what you were about to spend £50k/year licensing. It's not production-ready. It's probably held together with prompt-spit and optimism. But it works, and it cost you nothing but Dave's time and a Claude subscription.

This changes the calculus entirely. "Build" used to mean "commit a team for six months." Now it might mean "see what Dave can do by Thursday."

The smart move? Treat AI-assisted prototyping as a fourth option. Before you commit to build or buy, ask: can someone spike this in a week with AI assistance? If the answer is yes, you've just bought yourself information that makes the real decision much easier.

I'll cover vibe coding properly in a future post. For now, just know that the framework above isn't wrong - but there's a new variable in the equation that's getting harder to ignore.

Red flags in the decision process

Some patterns I've seen that predict bad outcomes:

"We'll build it faster than we could integrate it." This is almost always false. Integration is boring and predictable. Building is exciting and full of surprises.

"The vendor doesn't do exactly what we need." No vendor does exactly what you need. The question is whether the gap is big enough to justify building.

"We tried buying something before and it didn't work." This might mean buying is wrong for you. It might also mean you chose the wrong product, implemented it poorly, or had unrealistic expectations.

"Our developers are expensive, so building is efficient." This logic is backwards. Expensive developers should work on high-value problems, not commodity infrastructure.

"We don't trust vendors." If you can't trust any vendor, you have bigger problems than build vs buy. Modern businesses require vendor relationships.

The role of independent advice

Here's where I have to acknowledge my own bias: I consult on these decisions, so I have an interest in people seeking advice.

But here's the reality: internal teams are poorly positioned to make this decision objectively.

The engineering team has a bias toward building. The procurement team has a bias toward buying. The executive team has a bias toward whatever sounds fastest.

An independent advisor has no stake in which direction you go. I don't sell software and I don't have developers who need projects. I just want you to make the decision that serves your business.

That independence matters. Some of my best client outcomes have come from telling engineering teams "you're right, you should build this" when executives wanted to buy. And equally from telling executives "the team's enthusiasm for building is misplaced; buy this one."

The decision checklist

For any build vs buy decision, work through these:

  • Is this core to our competitive advantage?
  • Do we have realistic cost estimates for both options?
  • Have we included ongoing maintenance and evolution?
  • What's our confidence level in our requirements?
  • What's the switching cost if we're wrong?
  • What's the risk of a potential vendor going under?
  • Is there a hybrid (buy and extend) option?
  • What could Dave do by Thursday?
  • Are we making this decision based on evidence or emotions?
  • Have we got independent validation of our thinking?

The goal isn't to always build or always buy. The goal is to make the right choice for this specific situation, based on evidence rather than bias.

Facing a significant build vs buy decision? An independent assessment can help you see past the internal politics.

Related: Platform bets matter. I explored this pattern in Docker before 1.0 in The Long View.