The Build-vs-Buy Question Nobody Answers Honestly
Every build-vs-buy conversation starts the same way: someone pulls up a pricing page, someone else says “we could build that in a sprint,” and the meeting turns into a debate about the wrong question.
The wrong question is “can we build this.” Almost anything can be built. The question that actually predicts regret two years out is: who owns this thing when the person who built it leaves?
The framework
Three axes, in order of how often teams skip them:
1. Is this core to what you sell, or infrastructure underneath it? If customers are paying for it directly, lean build — you want control over the roadmap. If it’s infrastructure (auth, payments, observability), the default should be buy or self-host an existing open-source tool, not build from scratch. Nobody’s differentiator is their internal deploy dashboard.
2. What’s the real maintenance cost, not the build cost? The build is a few weeks. The maintenance is forever — security patches, the framework upgrade nobody wants to do, the on-call rotation for a system three people understand. Price the five-year cost, not the sprint estimate.
3. What’s the migration cost if you’re wrong? This is the one nobody prices in advance. A SaaS tool you can cancel next month. A hand-rolled internal system with two years of undocumented business logic baked in is a multi-quarter migration project waiting to happen. Weight decisions toward reversibility when you’re not sure.
Where this framework breaks
It’s not universal. Sometimes the “boring” infrastructure choice is your differentiator — a database company’s storage engine isn’t infrastructure to skip, it’s the product. Know which category you’re actually in before applying the framework, not after.
The honest version of the conversation
Instead of “can we build this,” ask: “if I leave the company in 18 months, does this decision look smart to whoever inherits it?” That question surfaces the maintenance and migration costs the sprint-estimate conversation always skips.