Your startup needs authentication, payments, email delivery, analytics, file storage, and a dozen other features. For each one, you face the same question: build it yourself or integrate a third-party service?

The answer isn't obvious. Build too much and you'll never ship. Buy too much and you'll hit a ceiling when your needs diverge from what the service provides.

Here's a framework for making these decisions systematically.

## Quick Answer

| Feature Type | Recommendation | Why |
|--------------|----------------|-----|
| **Commodity infrastructure** | Buy | Auth, payments, email, storage are solved problems |
| **Core differentiator** | Build | Your competitive advantage shouldn't depend on a vendor |
| **Complex with low differentiation** | Buy + customize | Search (Algolia), maps (Mapbox), video (Mux) |
| **Simple but strategic** | Build | When you need full control over the experience |
| **Uncertain requirements** | Buy first | Switch to build if you hit limitations |

The pattern: Buy commodities, build differentiators, stay flexible on everything else.

## The Build vs Buy Spectrum

This isn't a binary choice. Features fall on a spectrum from "obviously buy" to "obviously build."

### Obviously Buy (Commodity Layer)

| Feature | Services | Why Buy |
|---------|----------|---------|
| **Authentication** | Auth0, Clerk, Supabase Auth | Security is critical, UX is standardized |
| **Payments** | Stripe, PayPal | Compliance is complex, APIs are mature |
| **Email delivery** | Resend, Postmark, SendGrid | Deliverability is hard, features are standard |
| **File storage** | S3, Cloudflare R2 | Infrastructure is solved, scale matters |
| **Logging/monitoring** | Datadog, Sentry | Setup is fast, value is immediate |

These features have no competitive advantage. Your users don't care who handles your authentication. They expect it to work. Spending engineering time here is almost always a mistake.

### Obviously Build (Differentiator Layer)

| Feature | Why Build |
|---------|-----------|
| **Core product logic** | This IS your product |
| **Novel algorithms** | Your IP, your competitive advantage |
| **Unique workflows** | Standard solutions won't fit |
| **Domain-specific processing** | No vendor understands your space |

If this feature is why customers choose you over competitors, build it. Depending on a vendor for your core value is renting your competitive advantage.

### The Gray Zone (Context-Dependent)

| Feature | Buy If... | Build If... |
|---------|-----------|-------------|
| **Search** | Standard search works | Relevance is a differentiator |
| **Notifications** | Basic push/email is enough | Complex rules, preferences, timing |
| **Analytics** | Standard metrics suffice | Custom metrics drive your business |
| **Chat/messaging** | Basic messaging works | Real-time, threading, moderation are core |
| **Scheduling** | Standard calendar integration | Complex availability, booking logic |

This is where the framework matters. The right answer depends on your specific context.

## Decision Framework

For each feature decision, evaluate these factors:

### 1. Strategic Importance

**Question:** Does this feature differentiate us from competitors?

| Score | Meaning | Recommendation |
|-------|---------|----------------|
| 1-2 | Commodity, no differentiation | Strong buy |
| 3 | Some customization needed | Buy + customize |
| 4-5 | Core to our value proposition | Strong build |

### 2. Complexity vs. Customization

**Question:** How complex is this to build vs. how much customization do we need?

| Low Complexity, Low Customization | High Complexity, Low Customization |
|-----------------------------------|-----------------------------------|
| Buy (why build something easy that you don't need to customize?) | Buy (let specialists handle complexity) |

| Low Complexity, High Customization | High Complexity, High Customization |
|------------------------------------|-------------------------------------|
| Build (easy to do exactly what you want) | Toughest case: Start with buy, plan to build if needed |

### 3. Time-to-Market Pressure

**Question:** How quickly do we need this?

| Timeline | Lean Toward |
|----------|-------------|
| **Weeks** | Buy (integration takes hours/days) |
| **Months** | Either is viable |
| **No hard deadline** | Build if strategically important |

Speed matters more in early stages. You can always build later when you have product-market fit.

### 4. Vendor Risk Assessment

**Question:** What happens if the vendor changes pricing, goes down, or shuts down?

| Risk Level | Characteristics | Approach |
|------------|-----------------|----------|
| **Low** | Multiple alternatives, easy migration, stable pricing | Buy confidently |
| **Medium** | Some lock-in, migration would take weeks | Buy with abstraction layer |
| **High** | Single vendor, proprietary data formats, critical path | Build or multi-vendor strategy |

### 5. Total Cost Analysis

**Question:** What's the real cost of each option?

**Buy costs:**
- Integration time (usually days to weeks)
- Monthly fees (often scaling with usage)
- Migration costs when you outgrow
- Opportunity cost of vendor limitations

**Build costs:**
- Development time (weeks to months)
- Ongoing maintenance (forever)
- Infrastructure and scaling
- Security and compliance burden

## Common Mistakes

| Mistake | Why It Happens | The Cost |
|---------|----------------|----------|
| **Building commodities** | "How hard can it be?" | Weeks wasted on solved problems |
| **Buying differentiators** | "We'll customize later" | You won't, and you'll be limited |
| **Ignoring vendor lock-in** | "We can always switch" | Migration costs 10x what you expect |
| **Over-engineering the abstraction** | "We might switch vendors" | Generic code that satisfies no one |
| **Deciding once, never revisiting** | Early decisions become permanent | You're stuck with suboptimal choices |

## The Abstraction Layer Strategy

When you buy, add a thin abstraction layer. This gives you flexibility without over-engineering.

```typescript
// Bad: Direct vendor calls scattered everywhere
await stripe.charges.create({ amount: 2000, ... });

// Good: Abstraction layer
interface PaymentProcessor {
  charge(amount: number, customerId: string): Promise<ChargeResult>;
  refund(chargeId: string): Promise<RefundResult>;
}

class StripeProcessor implements PaymentProcessor {
  // Implementation details isolated here
}

// Usage (vendor-agnostic)
paymentProcessor.charge(2000, customerId);
```

This pattern lets you switch vendors without rewriting your entire codebase. But don't overdo it: build the abstraction you need today, not every possible feature you might need.

## Real Examples

### Example 1: Authentication for a B2B SaaS

**Context:** Building a B2B dashboard for enterprise clients. Need SSO, role-based access, and audit logs.

**Analysis:**
- Strategic importance: Low (users expect standard auth)
- Complexity: High (SSO, SCIM, audit logs)
- Time pressure: Moderate
- Vendor risk: Low (Auth0, Clerk, Supabase all viable)

**Decision:** Buy (Clerk or Auth0)

**Why:** Auth complexity explodes quickly. SSO integrations, session management, and security updates are a full-time job. Your engineers should focus on the product.

### Example 2: Recommendation Engine for E-commerce

**Context:** Building a niche marketplace. Product recommendations are a key differentiator.

**Analysis:**
- Strategic importance: High (better recommendations = more sales)
- Complexity: Medium (basic ML, not cutting-edge)
- Time pressure: Moderate
- Vendor risk: Medium (recommendations are core to product)

**Decision:** Build (with optional vendor for initial training data)

**Why:** Generic recommendation APIs won't understand your niche market. The algorithm IS the product. Start simple, improve over time.

### Example 3: Real-time Chat for a Collaboration Tool

**Context:** Building a project management tool. Chat is a feature, not the core product.

**Analysis:**
- Strategic importance: Medium (users expect it, but not a differentiator)
- Complexity: High (real-time, presence, history, search)
- Time pressure: High (competitors have it)
- Vendor risk: Medium (migration would be painful)

**Decision:** Buy first (Stream, Pusher, or similar), plan to build if it becomes strategic

**Why:** Real-time infrastructure is complex. Ship fast with a vendor. If chat becomes central to your product (unlikely based on positioning), build later.

## When to Revisit Build vs Buy

Early decisions aren't permanent. Re-evaluate when:

1. **Vendor pricing changes significantly** - The calculus shifts
2. **You hit vendor limitations repeatedly** - Workarounds are piling up
3. **The feature becomes strategic** - What was commodity is now differentiator
4. **You have excess engineering capacity** - Build debt becomes addressable
5. **The vendor's direction diverges from yours** - Their roadmap doesn't serve you

## Common Pitfalls

| Pitfall | Why It Happens | Fix |
|---------|----------------|-----|
| **Building for resume-driven development** | Engineers want to learn new tech | Build only what serves the business |
| **Buying without reading docs** | "We'll figure it out" | POC the integration before committing |
| **Abandoning vendor too early** | "We're hitting limits" | Are they real limits or implementation issues? |
| **Staying with vendor too long** | "Migration is too hard" | Compound interest on technical debt |
| **No clear ownership** | "Who decided this?" | Document decisions and rationale |

## Decision Template

For each significant feature, document:

```markdown
## Feature: [Name]

**Decision:** Build / Buy ([Vendor])
**Date:** YYYY-MM-DD
**Revisit by:** YYYY-MM-DD (or trigger event)

### Factors
- Strategic importance: [1-5]
- Complexity: [Low/Medium/High]
- Time pressure: [Weeks/Months/None]
- Vendor risk: [Low/Medium/High]

### Rationale
[2-3 sentences on why this decision makes sense]

### Alternatives Considered
[What else you evaluated]
```

This creates a paper trail for future team members and forces explicit reasoning.

---

The build vs buy decision shapes your product architecture, team focus, and long-term flexibility. If you're planning a new product and want guidance on which features to build vs buy, [book a consultation](https://innovativeprospects.com/contact). We've helped dozens of startups make these decisions, and we're happy to share what we've learned.