Build vs Buy

The Third Option Everyone Forgets

It’s never binary. Every capability has four postures:

 1. BUILD      in-house from scratch
 2. BUY        managed SaaS (Stripe, Twilio, Datadog)
 3. ADOPT      self-hosted open source (Postgres, Kafka, Keycloak)
 4. CONFIGURE  platform primitives (cloud queues, managed DBs)

 most real answers mix all four — per capability, decided deliberately

The Differentiation Test

The first filter is brutally simple:

 does this capability make customers choose US over competitors?

 NO (commodity): payments, email/SMS, auth plumbing, monitoring,
                 object storage, CI/CD
                 → default BUY/ADOPT; building burns roadmap on parity

 YES (core):     ride-matching algorithm, recommendation quality,
                 pricing engine, proprietary data pipelines
                 → BUILD; outsourcing the moat outsources the company
 
 borderline: things that are commodity today but strategic tomorrow
             → buy now behind an interface; revisit at trigger points

Total Cost of Ownership: The Honest Accounting

Sticker price misleads; TCO decides:

Cost line	Build	Buy
Initial engineering	months of team time	integration days
Ongoing engineering	upgrades, bugs, security patches	mostly vendor’s problem
Operational	you’re on-call for it	vendor is on-call
Flexibility	total	whatever API allows
Unit economics at scale	marginal cost approaches zero	bill grows with usage
Exit cost	low (it’s yours)	migration project

The crossover pattern: buying wins small and mid-scale; building wins at very large scale where unit costs dominate — which is why giants build databases and startups use Stripe.

Worked Decisions for RideShare

Capability	Call	Reasoning
Payment processing	Buy (PSP)	Commodity, compliance-heavy, differentiation zero
Push notifications	Buy	Same
Maps/routing	Buy (provider APIs)	World-class data unavailable otherwise
Driver matching	Build	The product; competitive core
Surge/pricing logic	Build	Direct revenue lever
Session storage	Adopt OSS (Redis)	Standard pattern, no vendor lock benefit

Note the interface discipline: bought services sit behind thin internal interfaces (PaymentProvider, MapsProvider) so any later swap is a new adapter, not a redesign.

Lock-In as a Priced Risk

Buying trades money for convenience and couples you to the vendor’s roadmap, pricing, and survival. Manage it as risk, not dogma:

• Prefer vendors with export paths and standard protocols.
• Keep data models portable even when compute isn’t.
• Price the exit annually (“if we left Stripe, what breaks?”) — unpriceable exits are the dangerous ones.

Interview Framing

Design interviews increasingly probe this: “would you build notifications?” Strong candidates answer with framework + verdict (“notifications are commodity — buy FCM/APNs behind a NotificationGateway interface; our matching engine is the opposite — that’s why the company exists”). Showing the interface seam converts the decision into architecture, which is what’s being graded.