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
1---2name: build-vs-buy3description: 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".4---56# Build vs. Buy Analysis78You 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.910## Process1112### Step 1: Define the Capability Need1314Clearly articulate what is being evaluated:1516| Field | Details |17|-------|---------|18| Capability needed | What the system or feature must do |19| Business driver | Why this capability is needed now |20| Core vs. context | Is this core to competitive advantage, or operational context? |21| Requirements (must-have) | Non-negotiable functional and non-functional requirements |22| Requirements (nice-to-have) | Desirable but not essential capabilities |23| Timeline | When must the capability be operational? |24| Expected lifespan | How long will this solution be needed (1 year, 5 years, 10+ years)? |25| Scale requirements | Users, transactions, data volume, growth projections |2627### Step 2: Evaluate Build Option2829Assess the cost and feasibility of building in-house:3031| Dimension | Assessment |32|-----------|------------|33| **Development effort** | Estimated person-months to build an MVP and full solution |34| **Team capability** | Does the team have the expertise? Hiring or training needed? |35| **Time to delivery** | How long until the solution is production-ready? |36| **Infrastructure cost** | Hosting, compute, storage, networking costs |37| **Ongoing maintenance** | Bug fixes, security patches, upgrades, on-call burden |38| **Opportunity cost** | What else could the team build with this time? |39| **Technical risk** | Complexity, unknowns, unproven approaches |40| **Customization** | Full control over features, UX, and roadmap |41| **Integration** | Effort to integrate with existing systems |42| **IP ownership** | Full ownership of the code and architecture |4344### Step 3: Evaluate Buy Option(s)4546Assess each vendor or product under consideration:4748| Dimension | Vendor A | Vendor B | Vendor C |49|-----------|----------|----------|----------|50| **License / subscription cost** | — | — | — |51| **Implementation cost** | — | — | — |52| **Customization effort** | — | — | — |53| **Integration effort** | — | — | — |54| **Capability coverage** | % of must-haves met | — | — |55| **Scalability** | — | — | — |56| **Security posture** | — | — | — |57| **Vendor stability** | Revenue, funding, market position | — | — |58| **Lock-in risk** | Data portability, contract terms | — | — |59| **Support quality** | SLAs, responsiveness, documentation | — | — |60| **Compliance** | SOC 2, GDPR, HIPAA, etc. | — | — |6162### Step 4: Total Cost of Ownership (TCO)6364Compare the three-year (or appropriate horizon) TCO:6566| Cost Category | Build | Buy (Vendor A) | Buy (Vendor B) |67|---------------|:---:|:---:|:---:|68| Initial development / implementation | — | — | — |69| Year 1 operating cost | — | — | — |70| Year 2 operating cost | — | — | — |71| Year 3 operating cost | — | — | — |72| Integration and migration | — | — | — |73| Training and onboarding | — | — | — |74| Maintenance and support | — | — | — |75| Opportunity cost (estimated) | — | — | — |76| **Total 3-year TCO** | **—** | **—** | **—** |7778Include hidden costs:79- Contract negotiation and procurement overhead80- Vendor management and relationship maintenance81- Switching costs if the vendor is replaced later82- Internal tooling and glue code to compensate for vendor gaps8384### Step 5: Decision Matrix8586Score each option against weighted criteria:8788| Criterion | Weight | Build | Buy (A) | Buy (B) |89|-----------|:---:|:---:|:---:|:---:|90| Capability fit (must-haves) | 25% | 1-5 | 1-5 | 1-5 |91| Total cost of ownership | 20% | 1-5 | 1-5 | 1-5 |92| Time to value | 15% | 1-5 | 1-5 | 1-5 |93| Strategic alignment | 15% | 1-5 | 1-5 | 1-5 |94| Maintenance burden | 10% | 1-5 | 1-5 | 1-5 |95| Risk profile | 10% | 1-5 | 1-5 | 1-5 |96| Flexibility / extensibility | 5% | 1-5 | 1-5 | 1-5 |97| **Weighted Score** | 100% | **—** | **—** | **—** |9899Adjust weights based on organizational priorities -- e.g., increase time-to-value weight if there is urgent market pressure.100101### Step 6: Risk Assessment102103Identify risks specific to each option:104105| Risk | Build | Buy | Mitigation |106|------|-------|-----|------------|107| Delivery delay | High if team is unfamiliar | Low if product is mature | Phased rollout, clear milestones |108| Vendor lock-in | N/A | High if data is not portable | Negotiate exit clauses, use open formats |109| Capability gaps | Low -- full control | Medium -- vendor roadmap may not align | Gap analysis, contractual commitments |110| Talent dependency | High -- key-person risk | Low -- vendor handles staffing | Documentation, cross-training |111| Security | Full control but full responsibility | Shared responsibility model | Security assessment, BAA/DPA |112| Vendor viability | N/A | Vendor could be acquired or shut down | Escrow agreements, evaluate financials |113114### Step 7: Recommendation115116State the recommendation clearly:117118| Decision | Rationale |119|----------|-----------|120| **Build** | When the capability is core to competitive advantage, requirements are highly unique, or long-term TCO favors in-house |121| **Buy** | When the capability is operational context, a mature product exists, and time-to-value is critical |122| **Hybrid** | Buy a platform and customize; or build the core and integrate vendor solutions for supporting features |123124## Output Format125126Present the analysis as a structured document:1271281. **Executive Summary** -- capability needed, recommendation (build/buy/hybrid), and top 3 reasons1292. **Capability Definition** -- what is needed and why1303. **Build Assessment** -- effort, timeline, cost, and risk1314. **Buy Assessment** -- vendor evaluations with capability coverage1325. **TCO Comparison** -- three-year cost table1336. **Decision Matrix** -- weighted scoring with justification1347. **Risk Comparison** -- risks by option with mitigations1358. **Recommendation** -- clear decision with supporting rationale1369. **Next Steps** -- action items to execute the decision (vendor selection, team staffing, timeline)137138## Quality Checklist139140- [ ] The capability need is clearly defined with must-have and nice-to-have requirements141- [ ] Core vs. context distinction is explicitly stated142- [ ] Build estimate includes maintenance and opportunity cost, not just initial development143- [ ] Buy estimate includes integration, customization, and switching costs144- [ ] At least two vendor options are evaluated (or reasons for a single-vendor analysis are stated)145- [ ] TCO covers a multi-year horizon appropriate to the decision146- [ ] Decision matrix weights are justified and tied to organizational priorities147- [ ] Risks are identified for both build and buy, not just one side148- [ ] Recommendation includes a clear rationale, not just a score149150## Edge Cases151152- **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 option153- **Open-source alternatives**: Treat open-source as a middle ground -- lower license cost but still requires implementation, integration, and maintenance investment154- **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 months155- **Regulatory constraints**: Some industries require data sovereignty or specific certifications that limit vendor options; document these constraints early156- **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 benefits157- **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
ashutoshsrivastava17