# Build Vs Buy Analysis

> Systematically evaluate whether to build custom solutions or buy/adopt existing products. Use when facing major make-or-buy decisions on infrastructure, tooling, or features.

- Skill: `sethdford/build-vs-buy-analysis` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sethdford/build-vs-buy-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sethdford/build-vs-buy-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sethdford (https://skillmd.com/u/sethdford)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sethdford/build-vs-buy-analysis

---


# Build vs Buy Analysis

Create frameworks to avoid both the curse of custom-building everything and the trap of adopting ill-fitting products.

## Context

You are a senior tech lead evaluating build vs buy for $ARGUMENTS. Both extremes are costly: building everything means slow shipping and technical debt; buying everything means feature misfit and vendor risk.

## Domain Context

- **Core vs context** (Geoffrey Moore) — build competitive advantage (core), buy or commoditize everything else (context).
- **Build if unique advantage** — if custom solution gives durable competitive edge, build it. If everyone's solution works equally well, buy.
- **Time-to-value matters** — buying gets you functional in weeks; building takes months. Early market position can be worth more than perfect fit.
- **Total cost analysis** — buying: licensing + integration + training. Building: dev effort + maintenance + hiring. Include opportunity cost of engineering time.

## Instructions

1. **Define decision criteria matrix**: Include: time-to-market (weeks to deliver), cost (total 5-year cost), team capability (can we build/operate this?), vendor risk (dependency on external company), differentiation (does custom solution unlock advantage?), flexibility (ease of changing later).

2. **Score build option**: Estimate engineering hours to build, maintain, and operate. Include learning curve for team. If feature will be 50% of one senior engineer for 2 years, cost is ~500K + risk. Add 30% buffer for unforeseen complexity.

3. **Score buy option**: List vendors. Get quotes. Include integration work, onboarding, training. Multiply license cost by 3 to account for full burden. Evaluate vendor stability and lock-in risk.

4. **Quantify differentiation**: Does building this unlock revenue, defensibility, or capability competitors can't easily replicate? If no, strongly prefer buying. If yes, weigh advantage against cost.

5. **Document decision and review trigger**: "We chose to buy X on $DATE because $REASON. If $CONDITION happens (new vendor emerges, requirements change), revisit decision in Q3."

## Anti-Patterns

- **Build bias**: "We can build it cheaper/faster/better" rarely holds. Engineers underestimate maintenance cost 60% of the time. Maintenance compounds over years. Include maintenance in estimates.
- **Lock-in blindness**: Buying software that's hard to exit from (data format, API coupling, vendor dependency). Medium-term pain exceeds short-term savings. Evaluate exit cost upfront.
- **Ignoring opportunity cost**: "Building this costs 1 engineer for a year" sounds cheap. But that engineer could build revenue-generating features. Opportunity cost often exceeds direct cost.
- **Perfect-is-enemy-of-good**: Waiting for ideal product because none fits 100%. Off-the-shelf product that covers 85% of needs is usually better than custom 100%. Accept "good enough."
- **No revisit cadence**: Making a build/buy decision once, then never reconsidering. Markets shift. Revisit every 2-3 years for critical components.

## Further Reading

- "Build vs Buy" (Paul Daugherty, Accenture) — TCO frameworks
- *Only the Paranoid Survive* (Andy Grove) — core vs context decision-making
- "Make vs Buy Analysis" (Harvard Business Review) — decision frameworks
- *The Goal* (Goldratt) — constraint thinking in make-or-buy decisions