build-vs-buy

name	build-vs-buy
description	Evaluate whether to build in-house, buy a vendor solution, or partner. Use when facing a make-or-buy decision for a capability.

Build vs. Buy Evaluation

Structure a build-vs-buy decision in half a day. Claude runs the comparison framework, models total cost of ownership, and maps the risk profile. You provide the strategic judgment about what's core to your product and what's commodity.

When to Use

• Evaluating a vendor solution vs. building in-house
• Deciding whether to integrate a third-party service or build your own
• Assessing whether to partner with another company for a capability
• Reviewing an existing vendor relationship (should we bring this in-house?)
• Engineering is proposing to build something that might already exist

When NOT to Use

• The decision is about pricing an existing product — use Pricing & Packaging
• You're evaluating competitive products for market analysis — use Discovery Process
• The decision is purely technical (language, framework) — defer to engineering

The AI-Native Approach

Step	Time	Claude Does	You Do
Define the capability	30 min	Structure requirements, must-haves vs. nice-to-haves	Validate requirements with stakeholders
Evaluate options	1-2 hrs	Research vendors, model build effort, map partner options	Add context from vendor conversations
Model total cost	1 hr	Calculate TCO for each option over 1-3 years	Validate engineering estimates
Assess strategic fit	30 min	Map options against strategic criteria	Make the core vs. commodity judgment
Recommend	30 min	Draft decision document with recommendation	Present and get sign-off

Process

Step 1: Define the Capability (30 minutes)

We need [capability] for [reason]. Help me structure the requirements:

Functional requirements:
- What must it do? (non-negotiable features)
- What should it do? (important but flexible)
- What could it do? (nice-to-haves, future needs)

Non-functional requirements:
- Performance: [latency, throughput, availability]
- Scale: [current and projected usage]
- Security/compliance: [requirements]
- Integration: [what it needs to connect to]
- Customization: [how much do we need to adapt it]

Constraints:
- Timeline: [when do we need this]
- Budget: [available investment]
- Team capacity: [who could build and maintain this]

Step 2: Evaluate Options (1-2 hours)

Evaluate three paths for this capability:

BUILD:
- Estimated effort to build (engineering weeks/months)
- What we'd build first (MVP) vs. full version
- Maintenance burden (ongoing engineering time)
- Time to first value
- What we control and can customize

BUY (evaluate 2-3 vendors if applicable):
For each vendor [names]:
- Feature coverage vs. our requirements
- Pricing model and estimated annual cost
- Integration complexity
- Vendor reliability (size, funding, customer base, track record)
- Lock-in risk (data portability, contract terms, switching cost)
- Customization limits

PARTNER:
- Are there companies that offer this as a white-label or co-build?
- What's the partnership structure (revenue share, co-development, licensing)?
- What do we give up (control, margin, data)?

Step 3: Model Total Cost of Ownership (1 hour)

Calculate TCO for each option over [1/2/3] years:

BUILD:
- Development cost: [engineering hours × loaded cost]
- Ongoing maintenance: [% of dev time per year]
- Infrastructure cost: [hosting, monitoring, tools]
- Opportunity cost: [what the team can't build while building this]
- Risk cost: [probability of failure × impact]

BUY:
- License/subscription cost: [annual]
- Integration cost: [engineering time to integrate]
- Ongoing integration maintenance: [annual]
- Training and change management: [one-time]
- Switching cost if we leave: [data migration, re-integration]
- Price escalation risk: [vendor raises prices]

PARTNER:
- Revenue share or licensing: [ongoing]
- Integration and co-development: [one-time + ongoing]
- Dependency risk: [partner changes terms, gets acquired, shuts down]

Present as a comparison table with 1-year and 3-year views.

Step 4: Assess Strategic Fit (30 minutes)

This is the judgment call that matters most.

Evaluate each option against strategic criteria:

Core vs. commodity:
- Is this capability a competitive differentiator for us?
- Do we need to innovate on this, or do we just need it to work?
- Would our users notice if we built this vs. bought it?

Speed vs. control:
- How urgently do we need this? (Buy is usually faster)
- How much customization do we need? (Build gives more control)
- How likely are requirements to change? (Build adapts faster to our needs)

Risk profile:
- Build risk: can we actually build this well with our team?
- Buy risk: vendor dependency, lock-in, price changes
- Partner risk: alignment of incentives, longevity

Team and culture:
- Does our team have the expertise to build and maintain this?
- Is building this a valuable skill-building opportunity?
- Or would it distract from our core mission?

Step 5: Recommend (30 minutes)

Draft a decision document:

1. Capability needed and why
2. Options evaluated (build, buy [vendors], partner)
3. TCO comparison (table)
4. Strategic fit assessment
5. Recommendation and rationale
6. Implementation plan for recommended option
7. Risks and mitigations
8. Decision deadline and review point

If recommending BUY: include vendor selection criteria and next steps (POC, trial, contract negotiation).
If recommending BUILD: include phased build plan and resource request.
If recommending PARTNER: include partnership structure and terms to negotiate.

Output

• Structured requirements (functional, non-functional, constraints)
• Option evaluation (build, buy, partner with specifics)
• TCO comparison table (1-year and 3-year)
• Strategic fit assessment
• Decision document with recommendation

Common Pitfalls

1. "We can build it better." Maybe. But should you? Building commodity infrastructure instead of product differentiation is the most common misallocation of engineering time.
2. Ignoring maintenance cost. Building is a one-time cost. Maintaining is forever. Factor in 15-20% of original build cost annually for maintenance.
3. Vendor lock-in fear. Some lock-in is acceptable for speed and focus. Evaluate the actual switching cost, not the theoretical risk. If switching cost is manageable, the lock-in concern may be overblown.
4. Not involving engineering. Build estimates from PMs are fiction. Engineering needs to evaluate feasibility, estimate effort, and assess maintenance burden.
5. Decision avoidance via POC. Proof of concepts are valuable, but "let's do a POC" can be a way to avoid deciding. Set clear POC success criteria and a decision deadline before starting.

Related Skills

• Tech Debt Communication — when "buy" replaces a homegrown system with debt
• Stakeholder Alignment — when the build-vs-buy decision involves cross-functional trade-offs
• Pricing & Packaging — when the vendor cost affects your product's unit economics