When to build vs buy: a framework I actually use

Engineering teams relitigate this question constantly: should we build it ourselves or use an existing solution? The debate usually goes in circles because people argue from intuition rather than criteria.

Here are the questions I actually ask.

Is This Your Core Business?

If what you're considering building is directly related to why your company exists and where you differentiate, build it. If it's infrastructure that every company at your scale needs and that specialised vendors have spent years on, buy it.

A fintech company should probably build its own risk engine. It should not build its own email delivery service. The former is differentiated IP; the latter is solved infrastructure. Using Sendgrid for email lets you spend engineering cycles on the thing that actually matters.

What's the Real Cost of Ownership?

The build cost is visible. The maintenance cost is invisible until it isn't. Every piece of internal tooling you write becomes someone's responsibility forever, or it becomes the thing nobody updates that breaks at the worst moment.

I try to estimate: how many engineer-hours per month will this require to maintain, handle incidents for, and keep up-to-date? Then I compare that to the SaaS cost. The break-even is often much further out than the initial build estimate suggests, because the initial estimate only accounts for building, not running.

How Fast Does This Space Move?

If you build something in a domain that's actively evolving, you're committing to keeping pace with that evolution. Build a search system in 2020 and you've now got an internal tool that competes with vendors who have absorbed years of LLM-era developments. The gap widens every year you don't invest in it.

Conversely, if the problem is well-understood and stable, building it yourself is lower risk: the solution you ship today won't be obsolete in eighteen months.

Is There an Integration Tax?

Sometimes you buy something and then spend six months wiring it into your stack, working around its data model, and writing adapters for every edge case it doesn't handle. The integration cost can dwarf the build cost. If the vendor's assumptions about your use case don't match your actual use case, the customisation tax compounds.

This is the hidden argument for building: you get exactly what you need, shaped to your actual data model and access patterns, with no impedance mismatch.

The Bottom Line

Default to buying for anything that isn't core business logic and where good solutions exist. Default to building when you have unusual requirements, when ownership of the behaviour matters, or when the maintenance burden is genuinely lower than vendor cost at your scale.

The worst outcome is building something that requires continuous investment to keep competitive with dedicated vendors. The second worst is buying something that fits so poorly you spend more engineering time on integration than you would have spent building. Both are avoidable with the right questions upfront.