When to build vs. buy: a framework for product teams

Every engineering organisation has a default. Some default to building — 'we can do this better ourselves' — and end up maintaining an internal auth system, a home-grown analytics platform, and a custom deployment tool while competitors ship new features. Others default to buying — 'there's a SaaS for everything' — and end up with 40 vendor integrations, fragile data pipelines between them, and a bill that scales with headcount.

Neither default is wrong. Both become wrong when applied without thinking.

The two questions that matter

Build vs. buy collapses to two questions. First: is this capability part of your core differentiation? Second: is the available solution a good enough fit for your specific requirements?

If the answer to the first question is yes, lean toward building. Your competitive advantage should not be rented. If competitors can buy the same capability, buying is appropriate — unless the vendor's one-size solution is a poor fit for your specific needs.

The hidden costs of buying

• Integration cost: connecting a vendor to your data model is never free
• Lock-in: switching costs compound over time as you build workflows around a vendor's API
• Pricing risk: usage-based pricing is cheap until it isn't
• Feature gaps: vendor roadmaps serve their median customer, not you

The hidden costs of building

• Opportunity cost: every hour on internal tooling is an hour not on product
• Maintenance burden: you now own this, forever
• Recruitment signal: engineers don't want to maintain internal CRUD tools
• Security responsibility: you inherit the vulnerability surface area

Buy to reach the table. Build to stay at it. Infrastructure, auth, payments, email delivery — buy. The core product experience that your customers pay for — build.

A practical heuristic

For anything below your application layer — infrastructure, authentication, payments, observability, communication — buy. The market is mature, the solutions are reliable, and your time is worth more than the customisation you'd gain from building.

For anything in your application layer that a paying customer directly experiences — the core workflow, the differentiating feature, the thing you would describe in a pitch — build. That's your moat, and you should own it completely.

For the grey zone — internal tools, data infrastructure, developer experience — evaluate on a 12-month horizon. If a vendor solution will cost you less than the engineering time to build and maintain an equivalent, buy. If you'll outgrow it or need deep customisation within a year, build. If you're not sure, buy and plan the migration.