build-vs-buy

What this skill does

# Build vs Buy Skill

When evaluating whether to build in-house or adopt an external solution, follow this structured process. The goal is to make a clear, data-driven recommendation that accounts for the full lifecycle — not just the initial build.

**IMPORTANT**: Always save the output as a markdown file in the `project-decisions/` directory at the project root. Create the directory if it doesn't exist.

## 0. Output Setup
```bash
# Create project-decisions directory if it doesn't exist
mkdir -p project-decisions

# File will be saved as:
# project-decisions/YYYY-MM-DD-build-vs-buy-[kebab-case-topic].md
# Example: project-decisions/2026-02-19-build-vs-buy-auth-system.md
```

## 1. Frame the Problem

### Define the Need

Before comparing options, get crystal clear on what you actually need:
```
What problem are we solving?
[Clear problem statement — not the solution, the problem]

Who needs it?
[Target users/systems — internal team, end users, API consumers]

What are the hard requirements? (must have)
1. [Requirement 1]
2. [Requirement 2]
3. [Requirement 3]

What are the soft requirements? (nice to have)
1. [Nice to have 1]
2. [Nice to have 2]

What are the constraints?
- Budget: [$ amount or range]
- Timeline: [when do we need this by?]
- Team capacity: [available engineering time]
- Compliance: [GDPR, SOC2, HIPAA, PCI, etc.]
- Scale: [users, requests, data volume]

What does success look like?
[Measurable outcome — e.g., "auth flow takes < 200ms, supports 10K concurrent users"]
```

### Check What Already Exists
```bash
# Do we already have something in this area?
grep -rn "[feature-keyword]" --include="*.ts" --include="*.js" --include="*.py" src/ app/ 2>/dev/null | grep -v "node_modules\|\.git\|test\|spec" | head -20

# Check existing dependencies
cat package.json 2>/dev/null | grep -i "[keyword]"
cat requirements.txt pyproject.toml 2>/dev/null | grep -i "[keyword]"
cat docker-compose.yml 2>/dev/null | grep -i "[keyword]"

# Check for existing integrations
grep -rn "api_key\|API_KEY\|client_id\|CLIENT_ID" --include="*.ts" --include="*.js" --include="*.py" --include="*.env*" . 2>/dev/null | grep -v "node_modules\|\.git" | grep -i "[keyword]"

# Check for previous decisions on this topic
ls project-decisions/ 2>/dev/null | grep -i "[keyword]"
grep -rn "[keyword]" --include="*.md" docs/ project-decisions/ 2>/dev/null
```

## 2. Define the Options

Always evaluate at least 3 options:
```
Option A: BUILD — Build in-house from scratch
Option B: BUY — Adopt [specific vendor/tool 1]
Option C: BUY — Adopt [specific vendor/tool 2]
Option D: HYBRID — Build core + use vendor for [specific part]
Option E: OPEN SOURCE — Use [OSS solution] and self-host
```

### Common Option Patterns

| Pattern | When It Works Best |
|---------|-------------------|
| **Build** | Core differentiator, unique requirements, full control needed, team has expertise |
| **Buy (SaaS)** | Commodity feature, time-to-market critical, team lacks expertise, managed service preferred |
| **Buy (Licensed)** | On-premise required, compliance restrictions, one-time cost preferred |
| **Open Source (managed)** | Need flexibility + support, community ecosystem matters |
| **Open Source (self-hosted)** | Cost-sensitive, team has ops capability, customization needed |
| **Hybrid** | Core logic is custom, but commodity parts (email, payments, auth) are bought |

## 3. Evaluate Each Option

### 3a. Feature Fit Analysis
```
| Requirement | Weight | Build | Buy (Vendor A) | Buy (Vendor B) | OSS |
|-------------|--------|-------|----------------|----------------|-----|
| [Must have 1] | 🔴 Must | ✅ Custom | ✅ Yes | ✅ Yes | ⚠️ Partial |
| [Must have 2] | 🔴 Must | ✅ Custom | ✅ Yes | ❌ No | ✅ Yes |
| [Must have 3] | 🔴 Must | ✅ Custom | ⚠️ Workaround | ✅ Yes | ✅ Yes |
| [Nice to have 1] | 🟡 Want | ❌ Not in v1 | ✅ Yes | ✅ Yes | ⚠️ Plugin |
| [Nice to have 2] | 🟡 Want | ❌ Not in v1 | ✅ Yes | ❌ No | ✅ Yes |
| [Nice to have 3] | 🟢 Nice | ❌ Future | ✅ Yes | ✅ Yes | ❌ No |
| **Feature Score** | | **3/3 must** | **2.5/3 must** | **2/3 must** | **2.5/3 must** |
```

Legend:
- ✅ Fully supported
- ⚠️ Partially supported or workaround needed
- ❌ Not supported
- 🔧 Requires customization

### 3b. Total Cost of Ownership (TCO) — 3 Year View

#### BUILD
```
| Cost Category | Year 1 | Year 2 | Year 3 | Total |
|---------------|--------|--------|--------|-------|
| **Initial Development** | | | | |
| Engineering (X devs × Y weeks × $rate) | $X | — | — | $X |
| Design / UX | $X | — | — | $X |
| Testing / QA | $X | — | — | $X |
| **Infrastructure** | | | | |
| Servers / Cloud | $X | $X | $X | $X |
| Database / Storage | $X | $X | $X | $X |
| Monitoring / Logging | $X | $X | $X | $X |
| **Ongoing Maintenance** | | | | |
| Bug fixes (X hrs/month × $rate) | $X | $X | $X | $X |
| Feature enhancements | $X | $X | $X | $X |
| Security patches | $X | $X | $X | $X |
| Dependency updates | $X | $X | $X | $X |
| On-call / operations | $X | $X | $X | $X |
| **Hidden Costs** | | | | |
| Knowledge transfer / documentation | $X | $X | — | $X |
| Opportunity cost (team not building features) | $X | $X | $X | $X |
| Recruitment (if specialized skills needed) | $X | — | — | $X |
| **TOTAL BUILD** | **$X** | **$X** | **$X** | **$X** |
```

#### BUY
```
| Cost Category | Year 1 | Year 2 | Year 3 | Total |
|---------------|--------|--------|--------|-------|
| **Subscription / License** | | | | |
| Base subscription (tier × price) | $X | $X | $X | $X |
| Per-user / per-seat cost | $X | $X | $X | $X |
| Overage charges (estimated) | $X | $X | $X | $X |
| **Integration** | | | | |
| Integration development | $X | — | — | $X |
| Data migration | $X | — | — | $X |
| Custom configuration | $X | — | — | $X |
| **Ongoing** | | | | |
| Integration maintenance | $X | $X | $X | $X |
| Vendor management | $X | $X | $X | $X |
| Training | $X | $X | — | $X |
| **Hidden Costs** | | | | |
| Price increases (assume X%/year) | — | $X | $X | $X |
| Migration cost (if switching later) | — | — | $X | $X |
| Workarounds for missing features | $X | $X | $X | $X |
| **TOTAL BUY** | **$X** | **$X** | **$X** | **$X** |
```

#### OPEN SOURCE (Self-Hosted)
```
| Cost Category | Year 1 | Year 2 | Year 3 | Total |
|---------------|--------|--------|--------|-------|
| **Setup** | | | | |
| Deployment / Configuration | $X | — | — | $X |
| Integration development | $X | — | — | $X |
| Customization | $X | — | — | $X |
| **Infrastructure** | | | | |
| Servers / Cloud | $X | $X | $X | $X |
| Database / Storage | $X | $X | $X | $X |
| **Ongoing** | | | | |
| Upgrades / Patches | $X | $X | $X | $X |
| Operations / Monitoring | $X | $X | $X | $X |
| Bug fixes / Contributions | $X | $X | $X | $X |
| Commercial support (optional) | $X | $X | $X | $X |
| **TOTAL OSS** | **$X** | **$X** | **$X** | **$X** |
```

#### TCO Comparison Summary
```
| | Year 1 | Year 2 | Year 3 | 3-Year Total |
|---|--------|--------|--------|-------------|
| BUILD | $X | $X | $X | $X |
| BUY (Vendor A) | $X | $X | $X | $X |
| BUY (Vendor B) | $X | $X | $X | $X |
| OSS (self-hosted) | $X | $X | $X | $X |
| HYBRID | $X | $X | $X | $X |
```

### 3c. Time to Value
```
| Option | Time to MVP | Time to Full Feature | Notes |
|--------|------------|---------------------|-------|
| BUILD | X weeks | X months | Need design + dev + test |
| BUY (Vendor A) | X days | X weeks | Integration time |
| BUY (Vendor B) | X days | X weeks | Integration time |
| OSS | X weeks | X weeks | Setup + customization |
| HYBRID | X weeks | X weeks | Fastest for core, buy rest |
```

### 3d. Risk Assessment

#### Build Risks
```
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| Takes longer than estimated | High | High | Phased delivery, MVP first |
| Team lacks domain expertise | Med | High | Hire / consult expert |
| Ongoing maintenance burden | High | Med | Dedicated on-call rotation |
| Key developer leaves | Med | High | Documentation, pair programming |
| Security vulnerabilities