Home/Operations/Build vs Buy / Outsourcing
Operations
intermediate📖 6 min read

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.

Real-World Example

Dropbox originally built their infrastructure on Amazon Web Services (AWS) because building cloud storage from scratch is incredibly expensive. However, as they scaled to exabytes of data, storage BECAME their core competency. The AWS premium became their biggest cost center. In 2016, they pulled a reverse-outsourcing maneuver called 'Project Magic Pocket', moving 90% of their data off AWS and onto their own custom-built infrastructure, saving $75 million in the first two years.

⚠️

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

1

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.

2

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.

3

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

Building in-house is always cheaper long-term

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.

Outsourcing means you lose control

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

55

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 →
📈

Industry Benchmarks

Process Efficiency

Post-Implementation

Elite

> 90%

Average

50-90%

Lagging

< 50%

🛠️

Recommended Tools

🎓

Go Deeper: Certifications

🎮

Decision Scenario: The Core Infrastructure Dilemma

You are the CTO of a fast-growing fintech startup. You need a robust KYC (Know Your Customer) and identity verification system to onboard users legally.

Engineering Capacity

2 Teams

Timeline constraint

3 Months

Decision 1

Your Lead Backend Engineer proposes building a custom KYC system using open-source ML models. 'It's literally our business to know our customers,' she argues. A vendor, Onfido, charges $1.50 per verification.

Approve the custom build. It saves unit economics in the long run.Click →
Your team spends 4 months building it. Launch is delayed. When it goes live, your system has a 12% false-positive rejection rate (industry standard is 3%). You lose thousands of real customers who couldn't scan their ID properly. You've outsourced your competitive advantage (user growth) to save $1.50 per user on an operationally complex, commoditized task.
Growth: Stalled by friction
Buy Onfido. Integrate their API and focus engineers on the core financial product.Click →
Integration takes 2 weeks. Onfido's ML models are trained on millions of IDs worldwide, giving you a 2% false-positive rate. Your conversion rate stays high. You pay the $1.50 'tax' but your engineers speed up the launch of your core lending product, generating $50 LTV per user. You easily absorb the vendor cost.
Time to Market: Fast
🧪

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?

Related Concepts

Turn knowledge into action

Try our free calculators to apply these concepts with your own numbers.

Try the Calculators →