The Question That Comes Up Every Sprint
"Should we build this ourselves or use a third-party service?" It's asked about authentication, payments, email, file storage, search, notifications, AI, analytics, and a dozen other capabilities in every product we build.
Get this decision wrong and you pay for it in one of two ways: either you spend 6 weeks building something that Stripe or Auth0 would have handled in 6 hours, or you're locked into a vendor that charges $3,000/month for something you could have built in a weekend at 1/100th the cost.
Here's the framework we use.
The Four-Variable Decision
Every build-vs-buy decision comes down to four variables:
1. Complexity: How complex is this capability? Is it a solved problem or a genuinely hard problem?
2. Differentiation: Does the quality of this capability differentiate your product in the market?
3. Scale: At your current and projected scale, what does each option cost?
4. Speed: What does each option cost in engineering time to implement and maintain?
Cases Where You Should Always Buy
Authentication
Auth is a solved problem. It's also a security-critical one. Rolling your own auth means:
- Managing password hashing, salting, and rotation
- Implementing MFA yourself
- Building email verification flows
- Handling session management and token rotation
- Staying current with OAuth 2.0, OIDC, and passkey standards
Use Auth0, Clerk, Supabase Auth, or NextAuth. The $0–$300/month at startup scale is trivially justified by the engineering time and security risk you avoid.
Exception: At very high scale (millions of MAU), vendor auth costs can become significant. Shopify, Airbnb, and GitHub all built their own auth eventually. You are not Airbnb yet.
Email Delivery
Email deliverability is a solved problem with deep expertise behind it. SPF, DKIM, DMARC, IP warming, bounce management, spam compliance - this is not where your engineering time should go.
Use SendGrid, Postmark, Resend, or AWS SES. Resend is particularly developer-friendly for new products.
Payment Processing
Never build a payment system. PCI-DSS compliance alone is a multi-month audit process. Stripe, Razorpay, and Paddle handle compliance, fraud detection, 3D Secure, and 100+ payment methods out of the box.
Build if: You're a financial institution with regulatory requirements that prohibit third-party payment processing. This is vanishingly rare.
SMS and Push Notifications
Twilio, Firebase Cloud Messaging, and AWS SNS exist specifically because managing carrier relationships and device push tokens is a full-time job. Use them.
Cases Where You Should Usually Build
Core Business Logic
The algorithms, rules, and workflows that make your product uniquely valuable to users should almost always be built. If you outsource the core of your product, you've outsourced your competitive advantage.
A job matching platform's matching algorithm should be built. Its email delivery should not.
Domain-Specific Data Models
Generic no-code tools for data management (Airtable, Notion) break down when your data model becomes complex or performance requirements increase. Build your own data layer when you have complex relationships, high write throughput, or specific query patterns.
Custom Reporting and Analytics
Third-party analytics tools (Mixpanel, Amplitude) are excellent for product analytics. But custom business reports - revenue by region, cohort retention by plan tier, inventory forecasting - are usually better as purpose-built SQL queries against your own database, rendered by your own frontend.
Cases That Are Genuinely It Depends
Search
Buy (Algolia, Typesense) if: your search needs are standard full-text search with typo tolerance, faceting, and good developer ergonomics. Algolia can be live in 2 hours.
Build (PostgreSQL full-text search, Elasticsearch) if: you're at a scale where Algolia's pricing ($0.50/1K searches) becomes significant, you need semantic/vector search deeply integrated with your data, or you need search behavior Algolia doesn't support.
For early-stage products: buy. For products with >10M monthly searches: evaluate seriously.
CMS
Buy (Sanity, Contentful, Strapi) if: non-technical team members need to manage content, you have complex content relationships, or you need a structured content API across multiple frontends.
Build if: your "content" is really structured product data (a marketplace listing is not a CMS use case), or your editing needs are simple enough for MDX files in your repo.
File Storage and Processing
Buy S3 for storage - it's not worth hosting your own. But for processing (video transcoding, image resizing, PDF generation), the "buy vs build" depends on volume. AWS MediaConvert is cost-effective at scale. Cloudinary is expensive at scale but saves weeks of integration time.
The Startup-to-Scale Shift
Many buy decisions at the startup stage become build decisions at scale. This is expected and fine - it means your product succeeded. Plan for it by:
- Abstracting third-party integrations behind your own interfaces (so you can swap vendors)
- Tracking the cost per unit of every third-party service (cost per email, cost per SMS, cost per search)
- Setting a "build threshold" - if vendor cost exceeds the annualized cost of 1 engineer's time to build and maintain it, evaluate building
The goal isn't to minimize build decisions or buy decisions. It's to maximize the speed at which you validate your product and the leverage each engineering hour gives you.