What does the Build vs Buy Decision Engine compare?

It compares two TCO curves over a configurable horizon — the cost of building and operating a component internally versus buying a managed service — and outputs a crossover point (if any), a per-component verdict, and a scoring of strategic-fit factors (differentiation, switching cost, compliance).

What kind of model is it?

It is a deterministic TCO tool — not a portfolio optimiser, not an org-design model.

Can I verify it with a worked example?

Yes. For auth: build = 200 hrs × $150/hr loaded = $30,000 one-time + maintenance 8 hrs/mo × $150 × 12 = $14,400/yr, so first-year build $44,400; buy = Clerk Pro $215/mo = $2,580/yr. The engine compares annual build total vs annual buy: $44,400 > $2,580 → verdict BUY.

Methodology: Build vs Buy Decision Engine

1. Scope

The Build vs Buy Decision Engine compares the annual cost of building and maintaining a component in-house against the annual cost of the managed-service alternative. For each enabled component it outputs a one-time build cost, an annual maintenance cost, an annual build-vs-buy comparison, a break-even point in months where one exists, and a BUILD or BUY verdict. It values your time at a single hourly rate. It does not score differentiation, switching cost, or compliance, and it does not discount a multi-year horizon.

2. Inputs and outputs

Inputs: one hourly value for your time. Then, per component (auth, database, hosting, payments, email, monitoring, analytics): whether it is enabled, hours to build it, maintenance hours per month, and the managed-service cost per month.

Outputs: per component — one-time build cost (build hours × hourly value), annual maintenance cost (maintenance hours × hourly value × 12), total annual build cost, annual buy cost (monthly × 12), break-even months where building eventually costs less, and a BUILD or BUY verdict with a one-line reason. Plus stack totals, an overall verdict, and a plain-language insight. There is no "hybrid" verdict.

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

3. Formula / scoring logic

# Per component, with your time valued at hourly_value
build_one_time     = build_hours * hourly_value
annual_maintenance = maintenance_hours_per_month * hourly_value * 12
annual_build_total = build_one_time + annual_maintenance
annual_buy         = managed_service_cost_per_month * 12

# Break-even in months — only when the subscription beats monthly
# maintenance labour, otherwise undefined (building never catches up)
monthly_savings    = managed_service_cost - maintenance_hours * hourly_value
break_even_months  = build_one_time / monthly_savings      # null when monthly_savings <= 0

# Verdict is a first-year comparison (full build cost charged to year one)
verdict = annual_build_total < annual_buy ? "BUILD" : "BUY"

4. Assumptions

Your time has one price. Every build and maintenance hour is valued at the single hourly rate you enter. Set it to your true loaded opportunity cost, not a nominal salary rate.
Build cost is a point estimate. Software estimates are famously wrong — an estimated 3-month build often runs 6. The tool applies no padding factor; pad the build-hours input yourself.
Maintenance is a monthly labour line. Ongoing bugs, security, and upgrades enter as maintenance hours per month, valued at the same hourly rate.
Buy-side pricing is the monthly cost you enter. Enterprise-negotiated rates, annual-commitment discounts, and volume tiers are your job to reflect in that figure.
Verdict is a first-year comparison. The full build cost is charged to year one, so anything with a large upfront build leans BUY. The break-even months output shows when a longer horizon flips the answer.

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 not modelled. Migrating off a built or bought component later carries real cost the tool does not price.
Strategic fit is out of scope. The verdict is pure cost. A component that is your actual product edge may be worth building even when the numbers say BUY — that judgment stays with you.
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

Input
Hourly value = $150. Component: auth — build = 200 hours, maintenance = 8 hours/month, managed-service = Clerk Pro at $215/mo.

Expected output
build_one_time = 200 × $150 = $30,000. annual_maintenance = 8 × $150 × 12 = $14,400. annual_build_total = $44,400. annual_buy = $215 × 12 = $2,580. Monthly maintenance labour alone ($1,200) already exceeds the $215/mo subscription, so building never breaks even. Verdict = BUY.

8. Change log

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

Worked example

Run live against the same engine this site ships (/engines/build-vs-buy-decision-engine.js). The inputs and outputs below are recomputed on every build and independently re-verified in CI — they are never hand-authored.

Input

tool: build_vs_buy_decision_engine
hourly_value: 100
components[0].name: auth
components[0].enabled: true
components[0].time_to_build_hours: 40
components[0].maintenance_hours_per_month: 4
components[0].managed_service_cost: 25
components[1].name: database
components[1].enabled: true
components[1].time_to_build_hours: 20
components[1].maintenance_hours_per_month: 2
components[1].managed_service_cost: 25

Output

components[0].name: Auth
components[0].buildCostOneTime: 4000
components[0].annualMaintenanceCost: 4800
components[0].annualBuildTotalCost: 8800
components[0].annualBuyCost: 300
components[0].verdict: BUY
components[0].reasoning: Buying Auth at $25/mo costs $300/year but saves 40h upfront + 4h/mo of your time ($8800/year equivalent).
components[1].name: Database
components[1].buildCostOneTime: 2000
components[1].annualMaintenanceCost: 2400
components[1].annualBuildTotalCost: 4400
components[1].annualBuyCost: 300
components[1].verdict: BUY
components[1].reasoning: Buying Database at $25/mo costs $300/year but saves 20h upfront + 2h/mo of your time ($4400/year equivalent).
totalBuildHours: 60
totalAnnualBuildCost: 13200
totalAnnualBuyCost: 600
annualSavings: 12600
overallVerdict: BUY
insight: Building everything yourself costs $13200/year in your time. Buying saves 6 hours/month for $50/month. At $100/hour, buying frees up time worth more than the subscription cost.

Frequently asked questions

What does the Build vs Buy Decision Engine compare?: It compares two TCO curves over a configurable horizon — the cost of building and operating a component internally versus buying a managed service — and outputs a crossover point (if any), a per-component verdict, and a scoring of strategic-fit factors (differentiation, switching cost, compliance).
What kind of model is it?: It is a deterministic TCO tool — not a portfolio optimiser, not an org-design model.
Can I verify it with a worked example?: Yes. For auth: build = 200 hrs × $150/hr loaded = $30,000 one-time + maintenance 8 hrs/mo × $150 × 12 = $14,400/yr, so first-year build $44,400; buy = Clerk Pro $215/mo = $2,580/yr. The engine compares annual build total vs annual buy: $44,400 > $2,580 → verdict BUY.