Build vs Buy
2 min read
Building in-house is cheaper at small scale, more expensive at large scale — and the crossover is different for every category.
Building in-house is cheaper at small scale, more expensive at large scale — and the crossover is different for every category.
How It Works
Every piece of infrastructure is either built in-house or bought (managed service, SaaS, open-source self-hosted). The build-vs-buy decision turns on three factors: (1) core competency — are we in the business of running this? (2) scale — is our load big enough to outgrow vendor pricing? (3) customization needs — do vendor constraints hurt the product? Common default: BUY for commodity infrastructure (email, auth, payments, analytics) unless you're at hyperscale; BUILD for core product differentiation (your ranking algorithm, your matching logic). Common failure modes: building commodity systems (losing years of engineering to rebuilding an inferior Mailgun), or buying core systems (ceding competitive advantage to a vendor).
Real-World Example
Netflix runs its own CDN (Open Connect) because at their scale, commercial CDNs couldn't serve their bandwidth economically. But they use AWS for compute because "building a hyperscale cloud" isn't their core business. The crossover was specific — CDN economics at 200+ Tbps flipped to favor in-house; compute economics did not. Compare to Slack, which uses AWS for everything including video infrastructure — their scale never flipped the calculation, and their differentiation is workflow + integrations, not media infrastructure. Each company drew the line where it mattered for THEIR scale and THEIR differentiation.
Test Yourself
Scenario: Your company needs transactional email (password reset, welcome, notifications). Build in-house or use a SaaS like SendGrid or Postmark? Justify.
Get notified when we launch
One email when the full practice product is live. No spam.