Use this when the team is deciding whether to build a capability in-house, buy a commercial product, or adopt an open-source solution. Covers total cost of ownership, strategic alignment, team capability, and long-term maintainability.

Related skills: Use /decision-brief for the options-and-tradeoffs format. Use /vendor-security-assessment for evaluating vendor security. Use /vendor-evaluation for structured vendor comparison. Use /adr-generate for documenting the decision. Use /technology-roadmap for portfolio context.

Process

Step 1: Gather inputs

Collect from the decision maker:

• Capability needed -- specific requirements, not just a category (not "we need an email service" but "we need transactional email with template management, delivery tracking, and 99.9% SLA for 500K sends/month")
• Current team skills and capacity -- who would build/integrate this, and what else are they working on
• Timeline pressure -- when does this capability need to be in production
• Strategic importance -- is this a core differentiator or commodity infrastructure
• Integration requirements -- what existing systems must this connect to
• Compliance/security constraints -- data residency, encryption, audit requirements
• Budget -- available budget for licensing, infrastructure, and engineering time

Step 2: Define evaluation criteria

Use these standard criteria. Ask the user to adjust weights based on their priorities (weights must sum to 100):

Step 3: Evaluate Option A -- Build

Estimate honestly (engineers chronically underestimate build costs):

• Engineering effort: {{X}} team-months to initial production
• Ongoing maintenance: {{15-25}}% of build cost per year (this is the number teams always forget)
• Time to production: {{X}} months
• 3-year TCO: Build cost + (3 x annual maintenance) + infrastructure
• Risks: Timeline slippage, talent dependency (what if the builder leaves), scope creep, opportunity cost (what else could the team be building)
• Advantages: Full control over functionality, exact fit for requirements, no vendor dependency, deep institutional knowledge

Step 4: Evaluate Option B -- Buy

Estimate the real cost, not just the license fee:

• Licensing cost (3-year TCO): Year 1 + Year 2 + Year 3 (account for price escalation)
• Implementation/integration effort: {{X}} team-months
• Ongoing integration maintenance: {{X}} team-months/year
• Vendor evaluation: Reference /vendor-evaluation for structured comparison if multiple vendors
• 3-year TCO: Licensing + implementation + (3 x integration maintenance) + infrastructure delta
• Risks: Vendor lock-in, feature gaps requiring workarounds, pricing changes at renewal, vendor viability, data migration complexity if switching
• Advantages: Faster time to value, maintained and updated by vendor, proven at scale, support available

Step 5: Evaluate Option C -- Adopt open-source

Estimate the real cost (open-source is free like a puppy is free):

• Integration effort: {{X}} team-months to production
• Internal maintenance/contribution cost: {{X}} team-months/year
• Community health: Contributors (active count), release cadence, governance model, corporate backing
• 3-year TCO: Integration + (3 x maintenance) + infrastructure + internal expertise development
• Risks: Project abandonment, security vulnerabilities without commercial support, breaking changes in major versions, support gaps for edge cases
• Advantages: No licensing cost, full source transparency, customizable, community ecosystem

Step 6: Generate scored comparison matrix

# Build vs Buy vs Adopt -- {{capability_name}}

## Evaluation date: {{date}}
## Decision maker: {{name/role}}

| Criterion | Weight | Build | Buy | Adopt (OSS) |
|---|---|---|---|---|
| Initial implementation cost | {{w}} | {{score}}/5 | {{score}}/5 | {{score}}/5 |
| Ongoing cost (3-year TCO) | {{w}} | {{score}}/5 | {{score}}/5 | {{score}}/5 |
| Time to value | {{w}} | {{score}}/5 | {{score}}/5 | {{score}}/5 |
| Customizability | {{w}} | {{score}}/5 | {{score}}/5 | {{score}}/5 |
| Team expertise required | {{w}} | {{score}}/5 | {{score}}/5 | {{score}}/5 |
| Vendor lock-in risk | {{w}} | {{score}}/5 | {{score}}/5 | {{score}}/5 |
| Security/compliance | {{w}} | {{score}}/5 | {{score}}/5 | {{score}}/5 |
| Maintenance burden | {{w}} | {{score}}/5 | {{score}}/5 | {{score}}/5 |
| Scalability | {{w}} | {{score}}/5 | {{score}}/5 | {{score}}/5 |
| **Weighted total** | | **{{total}}** | **{{total}}** | **{{total}}** |

## 3-Year TCO comparison
| | Build | Buy | Adopt |
|---|---|---|---|
| Year 1 | {{$}} | {{$}} | {{$}} |
| Year 2 | {{$}} | {{$}} | {{$}} |
| Year 3 | {{$}} | {{$}} | {{$}} |
| **Total** | **{{$}}** | **{{$}}** | **{{$}}** |

## Key differentiators
{{What makes each option stand out, positive and negative}}

Step 7: Produce recommendation

## Recommendation

**Recommended option:** {{Build / Buy / Adopt}}

**Rationale:** {{2-3 sentences explaining why this option wins}}

**Honest tradeoffs:** {{What you're giving up by choosing this option}}

**Key risk to watch:** {{The single biggest risk with this choice}}

**Revisit triggers:** Re-evaluate this decision if:
- {{Condition 1, e.g., "team grows beyond 20 engineers"}}
- {{Condition 2, e.g., "vendor raises prices more than 20% at renewal"}}
- {{Condition 3, e.g., "the OSS project loses its primary maintainer"}}

**Cost of switching later:** {{What it would take to reverse this decision}}

Step 8: Review

Before finalizing, ask:

• Are the cost estimates realistic, or are we being optimistic about build timelines and pessimistic about vendor pricing (or vice versa)?
• Is the team being honest about maintenance burden? (Build maintenance is always higher than estimated.)
• Are there strategic factors that override the scorecard? (Sometimes you build a commodity because it's your competitive moat.)
• Does this decision need an ADR? (Usually yes -- use /adr-generate.)
• Who else needs to weigh in before this is final?

Output location

Save to deliverables/build-vs-buy-{{capability_name}}-{{date}}.md. If an ADR is generated, link to it from the recommendation.