How Build vs Buy Decision Engine works

1. Scope

The Build vs Buy Decision Engine compares two TCO curves over a configurable horizon — the cost of building and operating a component internally versus the cost of buying a managed service. It outputs a crossover point (if any), a per-component verdict, and a scoring of strategic-fit factors (differentiation, switching cost, compliance). It is a deterministic TCO tool — not a portfolio optimiser, not an org-design model.

2. Inputs and outputs

Inputs: per-component — build cost (engineering hours × loaded rate), ongoing maintenance hours per month, infrastructure cost, and the buy alternative's monthly subscription at the relevant user scale. Also: differentiation score (is this component a source of competitive advantage?), switching-cost score, and compliance burden.

Outputs: cumulative build TCO and buy TCO over the horizon, breakeven month (if any), per-component verdict (build / buy / hybrid), and a plain-language summary.

Engine source: src/lib/build-vs-buy-decision-engine/engine.ts.

3. Formula / scoring logic

# TCO curves
build_tco(m)  = initial_build_cost + (maintenance_hours * hourly_rate + infra_cost) * m
buy_tco(m)    = subscription_price_monthly * m

# Breakeven month
breakeven_m   = initial_build_cost / (subscription - maintenance*hourly - infra)
                (defined when buy cost > build-running cost)

# Verdict
if breakeven_m <= horizon AND differentiation_score >= threshold:
    verdict = "build"
elif breakeven_m > horizon OR strategic_fit_score < threshold:
    verdict = "buy"
else:
    verdict = "hybrid"   # build the differentiated core, buy the commodity layer

4. Assumptions

• Build cost is point-estimated. Software engineering estimates are famously wrong — an estimated 3-month build often runs 6. The tool surfaces a sensitivity panel but does not apply a built-in padding factor.
• Maintenance is not free. A built component carries ongoing engineering cost (bugs, security, compliance, upgrades). The tool treats maintenance as a monthly line item — typically 15–25% of the original build cost per year.
• Buy-side pricing is list. Enterprise-negotiated rates, annual-commitment discounts, and growth-volume tiers are user overrides.
• Single component at a time. For multi-component decisions (the Build-All-Or-Buy-the-Stack debate), run the tool once per component and read the portfolio.
• No opportunity cost of engineering time. Every hour spent building is an hour not spent on differentiated product work. The differentiation score captures this editorially; the tool does not quantify lost revenue.

5. Data sources

• BLS OEWS 15-1252 — Software Developers median wage (US) — for the hourly-rate anchor.
• Subscription-price references pulled from the AI Stack Cost Calculator methodology page's vendor sources (Anthropic, OpenAI, Vercel, Supabase, Clerk, Resend, etc.), all dated 2026-04-24.
• Jason Cohen — Developing Your Build-vs-Buy Strategy, public essay, 2014 (framework reference; not a numeric benchmark).

6. Known limitations

• Optimism bias in build estimates. Engineers routinely under-estimate; planning fallacy literature (Kahneman, 1979; Buehler, 1994) supports padding build-time estimates by 50–100%.
• Switching cost is under-captured. The tool accepts a switching-cost score (low / medium / high) but does not simulate the migration-away scenario in TCO terms.
• No risk-adjustment for build failure. Not every build completes. A 20% failure rate changes expected TCO meaningfully — the tool does not probabilistic-weight.
• Does not model vendor-lock risk. Price increases from a dominant vendor (the classic "we have you" negotiation) are real but not simulated.
• Compliance-heavy domains require additional analysis. HIPAA, SOC 2, PCI, GDPR-specific audit burdens are not priced into the default cost curves.

7. Reproducibility

8. Change log

• 2026-04-24methodology page first published. TCO formulation and verdict logic documented.