build-vs-buy

name	build-vs-buy
description	Build-vs-buy decision framework with TCO analysis, vendor evaluation, and migration planning. Activate when: evaluating build vs buy, comparing vendors, assessing make or buy decisions, analyzing total cost of ownership, planning vendor migrations, evaluating SaaS vs custom.

Build vs Buy Decision Framework

Decision Framework Overview

When to consider Build:
- Core differentiator (competitive advantage)
- Unique domain logic not served by existing products
- Need full control over roadmap and customization
- Existing solutions require heavy customization (>40% custom)
- Data sovereignty or compliance prevents third-party use

When to consider Buy:
- Commodity capability (auth, payments, email, monitoring)
- Time-to-market is critical
- Internal team lacks domain expertise
- Proven solutions exist with strong ecosystems
- Maintenance burden of build exceeds license cost

TCO Analysis (Total Cost of Ownership)

Build Cost Model

## Upfront Costs
Development:
  - Engineering hours × hourly rate
  - Design and architecture time
  - Testing and QA effort
  - Documentation creation
  - Infrastructure setup

Opportunity cost:
  - What else could the team build instead?
  - Revenue delayed by building vs buying

## Ongoing Costs (Annual)
Maintenance:
  - Bug fixes: ~20% of original development effort per year
  - Security patches and updates
  - Dependency upgrades
  - On-call and incident response

Operations:
  - Infrastructure (compute, storage, networking)
  - Monitoring and alerting tools
  - Backup and disaster recovery
  - Performance tuning

Evolution:
  - Feature enhancements
  - Scaling for growth
  - Integration with new systems
  - Technical debt reduction

People:
  - Knowledge concentration risk (bus factor)
  - Hiring and training specialists
  - Team turnover and ramp-up time

Buy Cost Model

## Upfront Costs
Procurement:
  - License or subscription fees
  - Implementation/consulting fees
  - Data migration effort
  - Integration development
  - User training

Customization:
  - Configuration and setup
  - Custom integrations
  - Workflow adaptation
  - Plugin/extension development

## Ongoing Costs (Annual)
Licensing:
  - Per-user or per-transaction fees
  - Tier upgrades as usage grows
  - Support plan costs
  - Add-on module costs

Integration maintenance:
  - API version upgrades
  - Custom integration fixes
  - Data sync monitoring

Operational:
  - Vendor management overhead
  - Contract renewals and negotiations
  - Compliance audits
  - Internal admin and configuration

Hidden costs:
  - Vendor lock-in switching costs
  - Feature limitations and workarounds
  - Downtime from vendor outages (outside your control)
  - Data export/portability limitations

TCO Comparison Template

| Cost Category        | Build (5yr) | Buy (5yr) |
|---------------------|-------------|-----------|
| Initial development | $XXX        | —         |
| Implementation      | —           | $XXX      |
| Integration         | $XXX        | $XXX      |
| License/subscription| —           | $XXX      |
| Infrastructure      | $XXX        | $XXX      |
| Maintenance (annual)| $XXX × 5   | $XXX × 5  |
| Support             | Internal    | $XXX × 5  |
| Training            | $XXX        | $XXX      |
| Opportunity cost    | $XXX        | —         |
| **Total**           | **$XXX**    | **$XXX**  |

Break-even point: Year [N] (where build becomes cheaper than buy)

Vendor Evaluation Criteria

Evaluation Scorecard

Score each criterion 1-5 (1=poor, 5=excellent), weight by importance.

| Criterion              | Weight | Vendor A | Vendor B | Build |
|------------------------|--------|----------|----------|-------|
| Feature fit            | 25%    |          |          |       |
| Integration capability | 20%    |          |          |       |
| Scalability            | 15%    |          |          |       |
| Security & compliance  | 15%    |          |          |       |
| Vendor stability       | 10%    |          |          |       |
| Support quality        | 10%    |          |          |       |
| Pricing model          | 5%     |          |          |       |
| **Weighted total**     | 100%   |          |          |       |

Feature Fit Assessment

For each required capability:

| Requirement          | Priority | Vendor A    | Vendor B    |
|---------------------|----------|-------------|-------------|
| [Feature 1]         | Must     | Native      | Plugin      |
| [Feature 2]         | Must     | Custom dev  | Native      |
| [Feature 3]         | Should   | Not available| Native     |
| [Feature 4]         | Could    | Native      | Not available|

Legend:
  Native         — Built-in, works out of the box
  Configuration  — Requires setup but no code
  Plugin         — Available via marketplace/extension
  Custom dev     — Requires custom development
  Not available  — Cannot be achieved

Vendor Due Diligence

Financial Health:
  - Revenue trend (growing, stable, declining?)
  - Funding status (bootstrapped, funded, public?)
  - Customer count and retention rate
  - Key customer references in your industry

Product Maturity:
  - Years in market
  - Release frequency and changelog quality
  - Public roadmap availability
  - API stability (breaking changes history)
  - Documentation quality and completeness

Security & Compliance:
  - SOC 2 Type II certification
  - GDPR compliance (if applicable)
  - Data residency options
  - Penetration testing cadence
  - Incident response track record
  - Encryption standards (at rest, in transit)

Support & SLA:
  - Support tiers and response times
  - Uptime SLA (99.9%? 99.99%?)
  - Penalty/credit structure for SLA violations
  - Dedicated account manager (at your tier?)
  - Community and self-service resources

Contract Terms:
  - Minimum commitment period
  - Price escalation caps
  - Data portability on exit
  - Termination for convenience clause
  - Auto-renewal terms

Integration Risk Assessment

Integration Complexity Matrix

| Integration Point    | Complexity | Risk  | Mitigation |
|---------------------|------------|-------|------------|
| Authentication (SSO)| Low        | Low   | Standard OIDC/SAML |
| Data sync (real-time)| High      | High  | Event-driven, idempotent |
| Reporting/BI        | Medium     | Low   | Read-only API |
| Workflow automation  | Medium    | Medium| Webhook + retry |
| Legacy system bridge | High      | High  | Adapter pattern |

Complexity factors:
  - Data format transformation required
  - Bi-directional sync needed
  - Real-time vs batch requirements
  - Error handling and retry complexity
  - Authentication and authorization model
  - Rate limiting and throttling

API Evaluation Checklist

- [ ] REST or GraphQL API available
- [ ] API documentation is complete and accurate
- [ ] API versioning strategy (URL, header, or query param)
- [ ] Rate limits are documented and sufficient
- [ ] Webhook support for event-driven integration
- [ ] Sandbox/test environment available
- [ ] SDK available in your language(s)
- [ ] Bulk/batch operations supported
- [ ] Pagination for large result sets
- [ ] Error responses are structured and documented
- [ ] API status page and incident communication

Vendor Lock-In Assessment

Lock-in risk factors (score each 1-5):

Data portability:
  - Can you export all your data? In what format?
  - Is the data schema documented?
  - How long does export take at your data volume?

Feature portability:
  - How much custom logic lives inside the vendor?
  - Are workflows exportable or vendor-specific?
  - Can configurations be version-controlled?

Integration coupling:
  - How many systems depend on this vendor's API?
  - Are you using vendor-specific features or standards?
  - Can you swap to an alternative without rewriting integrations?

Contractual lock-in:
  - Multi-year commitment required?
  - Penalty for early termination?
  - Data held hostage after contract ends?

Total lock-in score:
  4-8:  Low risk (easy to switch)
  9-14: Medium risk (switching is painful but feasible)
  15-20: High risk (significant switching cost; plan mitigation)

Migration Planning

Migration Phases

Phase 1: Assessment
  - Inventory current system capabilities
  - Map data entities and relationships
  - Identify integration dependencies
  - Document business rules embedded in current system
  - Assess user workflows and training needs

Phase 2: Planning
  - Define data migration strategy (big-bang vs incremental)
  - Design integration architecture
  - Plan parallel running period
  - Create rollback strategy
  - Build test plan for migration validation

Phase 3: Execution
  - Set up target system
  - Develop and test data migration scripts
  - Build integrations
  - Migrate data (with validation checkpoints)
  - Run parallel systems during transition

Phase 4: Cutover
  - Final data sync
  - Switch traffic to new system
  - Monitor for issues
  - Decommission old system (after bake period)

Phase 5: Stabilization
  - Address post-migration issues
  - Optimize performance
  - Complete user training
  - Document lessons learned

Data Migration Checklist

- [ ] Complete data inventory (entities, volumes, relationships)
- [ ] Field-level mapping between source and target
- [ ] Data cleansing rules defined (dedup, format, validation)
- [ ] Migration scripts developed and tested
- [ ] Dry run completed on production-like data
- [ ] Data validation queries prepared (row counts, checksums)
- [ ] Rollback procedure tested
- [ ] Cutover window scheduled with stakeholders
- [ ] Post-migration verification plan ready

Decision Documentation Template

# Build vs Buy Decision: [Capability Name]

## Context
- Business need: [what problem are we solving]
- Timeline: [when do we need it]
- Team capacity: [available engineering bandwidth]

## Options Evaluated
1. Build in-house
2. Vendor A: [name]
3. Vendor B: [name]

## Evaluation Summary
| Criterion | Build | Vendor A | Vendor B |
|-----------|-------|----------|----------|
| Feature fit | X/5 | X/5 | X/5 |
| Time to value | X/5 | X/5 | X/5 |
| 5-year TCO | $X | $X | $X |
| Lock-in risk | X/5 | X/5 | X/5 |
| Team capacity | X/5 | X/5 | X/5 |

## Decision
**Choice**: [Build / Vendor X]
**Rationale**: [2-3 sentences explaining the primary driver]
**Trade-offs accepted**: [what are we giving up]
**Review date**: [when to revisit this decision]

## Approved by
- [Name, Role, Date]