Build vs Buy Framework
The Framework
Every build-vs-buy decision really boils down to three questions: Is this a strategic differentiator for us? Can we handle the total cost of ownership? And do we have the right people to sustain it long-term?
Strategic Differentiation Matrix
Plot the capability on two axes: business differentiation (does this create unique value for your customers?) and technical complexity (how hard is it to build and keep running?).
High differentiation, any complexity means you should build. This is your competitive moat. Amazon built their own container orchestration before Kubernetes existed because compute orchestration was core to their business.
Low differentiation, low complexity means buy. Authentication, email delivery, payment processing: these are solved problems. Use Auth0, SendGrid, Stripe.
Low differentiation, high complexity means definitely buy. Monitoring, databases, CI/CD. You're never going to build a better Datadog or PostgreSQL. Point your engineers at the things that make your product unique.
High differentiation, high complexity means build, but take it in phases. Start with a purchased solution to validate the market, then progressively replace it with custom software as you learn what actually differentiates you.
Total Cost of Ownership Calculation
For a build decision, calculate: (initial_dev_cost) + (annual_maintenance * years) + (opportunity_cost_of_engineers) + (operational_cost). A reasonable rule of thumb: maintenance runs about 15-20% of initial development cost per year.
For a buy decision, calculate: (license_fees * years) + (integration_cost) + (customization_cost) + (training_cost) + (migration_risk_cost). Don't forget that SaaS pricing goes up. Budget for 10-15% annual price increases.
The Decision Meeting
Bring a one-page comparison. Include: your recommendation with reasoning, a 3-year TCO comparison, a risk matrix for each option, and an assessment of how reversible the decision is. Make the call with the smallest group that actually has the authority, usually the engineering manager, a product lead, and someone from finance. Write it up in an ADR so future teams understand why you went the direction you did.
Key Points
- •Compare total cost of ownership over 3 years, including maintenance, integration, training, and opportunity cost
- •Only build when the capability is a strategic differentiator. If it doesn't create competitive advantage, buy it
- •Be honest about team capability. Building something requires not just the initial development but years of keeping it running
- •Factor in time-to-market. Buying gets you to production in weeks, building might take quarters
- •Plan for the exit. Whether you build or buy, design integration layers so you can switch later without rewriting consumers
Common Mistakes
- ✗Comparing build cost against license cost only, and ignoring the ongoing maintenance burden of custom software
- ✗Letting engineer preference drive the decision. 'We could build that' is not a business justification
- ✗Not evaluating vendor lock-in risk. Some SaaS products make data extraction deliberately painful
- ✗Assuming building means better fit. Custom software has bugs too, and you're the only support team