| name | build-vs-buy |
| description | Analyze build vs. buy decisions with total cost of ownership, capability fit, maintenance burden, and strategic alignment. Produce recommendation with decision matrix and risk assessment. TRIGGER when: user says /build-vs-buy, "build vs buy", "build or buy", "make vs buy", or "vendor vs custom".
|
| argument-hint | [capability or system needed] |
| user-invocable | true |
Build vs. Buy Analysis
You are a senior engineer or technical strategist evaluating whether to build a capability in-house or purchase an existing solution. Produce a structured analysis covering total cost of ownership, capability fit, strategic alignment, and risk to support a well-informed decision.
Process
Step 1: Define the Capability Need
Clearly articulate what is being evaluated:
| Field | Details |
|---|
| Capability needed | What the system or feature must do |
| Business driver | Why this capability is needed now |
| Core vs. context | Is this core to competitive advantage, or operational context? |
| Requirements (must-have) | Non-negotiable functional and non-functional requirements |
| Requirements (nice-to-have) | Desirable but not essential capabilities |
| Timeline | When must the capability be operational? |
| Expected lifespan | How long will this solution be needed (1 year, 5 years, 10+ years)? |
| Scale requirements | Users, transactions, data volume, growth projections |
Step 2: Evaluate Build Option
Assess the cost and feasibility of building in-house:
| Dimension | Assessment |
|---|
| Development effort | Estimated person-months to build an MVP and full solution |
| Team capability | Does the team have the expertise? Hiring or training needed? |
| Time to delivery | How long until the solution is production-ready? |
| Infrastructure cost | Hosting, compute, storage, networking costs |
| Ongoing maintenance | Bug fixes, security patches, upgrades, on-call burden |
| Opportunity cost | What else could the team build with this time? |
| Technical risk | Complexity, unknowns, unproven approaches |
| Customization | Full control over features, UX, and roadmap |
| Integration | Effort to integrate with existing systems |
| IP ownership | Full ownership of the code and architecture |
Step 3: Evaluate Buy Option(s)
Assess each vendor or product under consideration:
| Dimension | Vendor A | Vendor B | Vendor C |
|---|
| License / subscription cost | — | — | — |
| Implementation cost | — | — | — |
| Customization effort | — | — | — |
| Integration effort | — | — | — |
| Capability coverage | % of must-haves met | — | — |
| Scalability | — | — | — |
| Security posture | — | — | — |
| Vendor stability | Revenue, funding, market position | — | — |
| Lock-in risk | Data portability, contract terms | — | — |
| Support quality | SLAs, responsiveness, documentation | — | — |
| Compliance | SOC 2, GDPR, HIPAA, etc. | — | — |
Step 4: Total Cost of Ownership (TCO)
Compare the three-year (or appropriate horizon) TCO:
| Cost Category | Build | Buy (Vendor A) | Buy (Vendor B) |
|---|
| Initial development / implementation | — | — | — |
| Year 1 operating cost | — | — | — |
| Year 2 operating cost | — | — | — |
| Year 3 operating cost | — | — | — |
| Integration and migration | — | — | — |
| Training and onboarding | — | — | — |
| Maintenance and support | — | — | — |
| Opportunity cost (estimated) | — | — | — |
| Total 3-year TCO | — | — | — |
Include hidden costs:
- Contract negotiation and procurement overhead
- Vendor management and relationship maintenance
- Switching costs if the vendor is replaced later
- Internal tooling and glue code to compensate for vendor gaps
Step 5: Decision Matrix
Score each option against weighted criteria:
| Criterion | Weight | Build | Buy (A) | Buy (B) |
|---|
| Capability fit (must-haves) | 25% | 1-5 | 1-5 | 1-5 |
| Total cost of ownership | 20% | 1-5 | 1-5 | 1-5 |
| Time to value | 15% | 1-5 | 1-5 | 1-5 |
| Strategic alignment | 15% | 1-5 | 1-5 | 1-5 |
| Maintenance burden | 10% | 1-5 | 1-5 | 1-5 |
| Risk profile | 10% | 1-5 | 1-5 | 1-5 |
| Flexibility / extensibility | 5% | 1-5 | 1-5 | 1-5 |
| Weighted Score | 100% | — | — | — |
Adjust weights based on organizational priorities -- e.g., increase time-to-value weight if there is urgent market pressure.
Step 6: Risk Assessment
Identify risks specific to each option:
| Risk | Build | Buy | Mitigation |
|---|
| Delivery delay | High if team is unfamiliar | Low if product is mature | Phased rollout, clear milestones |
| Vendor lock-in | N/A | High if data is not portable | Negotiate exit clauses, use open formats |
| Capability gaps | Low -- full control | Medium -- vendor roadmap may not align | Gap analysis, contractual commitments |
| Talent dependency | High -- key-person risk | Low -- vendor handles staffing | Documentation, cross-training |
| Security | Full control but full responsibility | Shared responsibility model | Security assessment, BAA/DPA |
| Vendor viability | N/A | Vendor could be acquired or shut down | Escrow agreements, evaluate financials |
Step 7: Recommendation
State the recommendation clearly:
| Decision | Rationale |
|---|
| Build | When the capability is core to competitive advantage, requirements are highly unique, or long-term TCO favors in-house |
| Buy | When the capability is operational context, a mature product exists, and time-to-value is critical |
| Hybrid | Buy a platform and customize; or build the core and integrate vendor solutions for supporting features |
Output Format
Present the analysis as a structured document:
- Executive Summary -- capability needed, recommendation (build/buy/hybrid), and top 3 reasons
- Capability Definition -- what is needed and why
- Build Assessment -- effort, timeline, cost, and risk
- Buy Assessment -- vendor evaluations with capability coverage
- TCO Comparison -- three-year cost table
- Decision Matrix -- weighted scoring with justification
- Risk Comparison -- risks by option with mitigations
- Recommendation -- clear decision with supporting rationale
- Next Steps -- action items to execute the decision (vendor selection, team staffing, timeline)
Quality Checklist
Edge Cases
- Hybrid approaches: When neither pure build nor pure buy fits, evaluate a hybrid -- buy a platform and build custom layers on top; score this as a separate option
- Open-source alternatives: Treat open-source as a middle ground -- lower license cost but still requires implementation, integration, and maintenance investment
- Rapidly evolving market: If the vendor landscape is immature, building may be premature; consider a short-term buy with a plan to re-evaluate in 12-18 months
- Regulatory constraints: Some industries require data sovereignty or specific certifications that limit vendor options; document these constraints early
- Team morale and growth: Factor in that building can develop team expertise and morale, while buying may free the team for higher-value work -- both have organizational benefits
- Sunk cost bias: If the organization has already started building, evaluate objectively whether continuing is truly better than switching -- do not let sunk cost drive the decision
