Build vs Buy / Outsourcing

Also known as: Build vs BuyOutsourcing DecisionMake vs BuyIn-House vs OutsourceVendor vs Build

Build TCO (3-year) = Dev Cost + (Annual Maintenance × 3) + Opportunity Cost

💡The Concept

The build vs buy decision determines whether you develop a capability in-house or outsource/purchase it. The core rule: build what's core to your competitive advantage, buy everything else. Building a custom CRM when your business is e-commerce wastes engineering on undifferentiated work. Slack built their messaging infra (core advantage) but bought Stripe for payments (commodity). Companies that misallocate build/buy decisions waste 20-30% of engineering capacity on projects that off-the-shelf tools handle better.

⚠️The Trap

The 'Not Invented Here' syndrome is deadly — engineering teams believe they can build a better version of existing tools. Custom-built billing systems, authentication, and analytics almost always cost 5-10x more than buying (SaaS fees for 5 years vs. building + maintaining). Hidden costs include: ongoing maintenance (20% of build cost annually), security patches, onboarding new engineers to custom systems, and opportunity cost of engineers NOT building your core product. Conversely, over-outsourcing core capabilities makes you dependent on vendors who can raise prices or shut down.

🎯The Action

For each build/buy decision, calculate the Total Cost of Ownership (TCO) over 3 years. For build: Development cost + (Annual maintenance × 3) + Opportunity cost of delayed core features. For buy: (Annual license × 3) + Integration cost + Switching cost risk. If the buy TCO is less than 50% of build TCO AND the capability isn't core to your competitive advantage, buy. Review all vendor contracts annually — a $500/month tool that your 5-person team used but your 50-person team outgrew becomes a scaling liability.

⚡Pro Tips

Apply the '10x rule': if building it yourself would take 10x longer than buying/integrating, it's almost always better to buy. Auth0 took a team of 50 security engineers 7 years to build. You're not going to replicate that with 2 engineers in 3 months.

The best outsourcing strategy is 'abstract the boundary.' Use an adapter pattern so you can swap vendors without rewriting your codebase. Wrap Stripe behind a PaymentService interface — if you outgrow Stripe (unlikely), swapping costs days, not months.

Outsource early, in-source later. Start with Heroku, move to AWS when you need the control. Start with Auth0, build custom auth only when you have 10M+ users and unique requirements. This lets you ship product while preserving the option to build later.

🚫Common Myths

✗Myth: “Building in-house is always cheaper long-term”

✓Reality: Basecamp calculated that their custom fork of Rails features cost $3.4M/year in dedicated engineer salaries to maintain — for capabilities that commercial tools provide for $50K/year. Only build when the capability IS your product or creates competitive advantage.

✗Myth: “Outsourcing means you lose control”

✓Reality: Modern SaaS tools offer APIs, webhooks, and data export. You control the data and the integration layer. Stripe processes $1 trillion/year for companies that 'outsource' their payments — none of them lost control. The key is choosing vendors with strong APIs and data portability.

📊Real-World Case Studies

🛒

Shopify

2006-Present

success

Shopify built their core e-commerce platform and POS system in-house (their competitive advantage) but outsourced payments to Stripe, email to SendGrid, and hosting to Google Cloud. This focus allowed a team of 200 engineers to serve 2M+ merchants. When they eventually brought payments partially in-house (Shopify Payments, powered by Stripe), it was at massive scale where the economics justified it — processing $61B in GMV in 2023.

Active Merchants

2M+

GMV (2023)

$235.9B

Engineering Team Size

~3,000

Build vs Buy Split

Core: build, Infra: buy

💡 Lesson: Shopify's build/buy discipline let them focus engineering on merchant-facing features that drove growth. They didn't build a CDN, an email system, or a payment processor from scratch until scale justified it — and even then, they partnered (Stripe) rather than building completely from zero.

Source →

🏥

Healthcare.gov

2013 Launch

failure

The US government spent $2.1 billion building Healthcare.gov, outsourcing to 55 different contractors with no single systems integrator. The launch was catastrophic — the site crashed under 250K simultaneous users (expected 50K). Only 6 people successfully enrolled on day 1. The root cause: outsourcing EVERYTHING including architecture decisions and quality control, with no in-house technical leadership.

Total Cost

$2.1B

Contractors Used

Day 1 Enrollments

6 people

Fix Timeline

3 months post-launch

💡 Lesson: Outsourcing execution is fine; outsourcing judgment is fatal. Healthcare.gov had no in-house technical leadership to evaluate vendor quality, manage integration, or make architecture decisions. The fix came when a small 'tech surge' team of 20 elite engineers (from Google, Palantir, etc.) took over coordination. Build/buy decisions need an informed buyer.

Source →

🧪

Scenario Challenge

Your 15-person SaaS startup needs user authentication with SSO, MFA, and RBAC. Your CTO wants to build it in-house: '3 engineers, 3 months, we'll own it forever.' Auth0 (a major vendor) costs $3,500/month for your user count. The 3 engineers earn $180K/year each ($45K/quarter). What should you do?

🧪 Challenge a Friend