Build vs Buy: Engine vs Decision Tree

Use the decision tree for fast, low-stakes triage and the build-vs-buy engine when the dollar magnitude matters: on a 3-component auth/database/hosting scenario at $100/hour, both reach the same "buy" verdict, but only the engine quantifies it ($17,560 saved per year, with break-even sensitivity). The tree is heuristics for speed; the engine is math for high-stakes calls. This article runs them on the same scenario, names what each catches that the other misses, and recommends the hybrid workflow most solo founders converge on.

1. Two approaches to the same question

The engine approach: take the build cost (engineering hours × hourly rate), the maintenance cost (recurring hours per month × hourly rate × 12), the vendor cost (subscription × 12), and compute the annual cost difference. The output is quantitative: $X annual savings, Y months to break-even, verdict BUILD or BUY per component.

The decision tree approach: ask a sequence of yes/no questions whose answers route to BUY or BUILD. Common questions:

1. Is the component regulated (payments, identity, healthcare, financial)? → BUY (always).
2. Is it core to your product differentiation? → BUILD (usually).
3. Does the vendor pricing scale faster than your revenue? → BUILD (eventually).
4. Can you describe the component's value in one sentence? → BUY (commodity).
5. Is there a clear migration path off the vendor in 30 days? → BUY (low lock-in risk).

The two approaches are complementary, not competitive. Joel Spolsky's 2001 essay^[1] defended build for core competencies; Martin Fowler's make-buy-lease framework^[2] codified the tree-style heuristics; MIT Sloan's strategic outsourcing framework^[5] integrates both into a unified decision process. The engine is the quantitative expression of these qualitative frameworks.

2. Where the engine wins: concrete math, multiple components

The engine has three structural advantages.

Dollar magnitude. "BUY" as a verdict is informative; "BUY, saving $17,560/year" is actionable. The dollar magnitude tells you whether the decision is worth optimizing further (small savings: just buy and move on) or worth a deeper review (large savings: validate the inputs carefully).

Per-component detail. A decision tree gives one answer per question. The engine gives one answer per component evaluated in parallel. For a stack decision involving 4-7 components (auth, database, hosting, payments, monitoring, email), the engine produces a complete picture; the tree requires repeated independent runs.

Sensitivity analysis. The engine's break-even months output ("the build pays back in 24 months at this hourly rate, never at $50/hour") gives you the lever to interrogate the decision. A decision tree's binary output does not. Sensitivity analysis matters when the inputs are uncertain — which they always are at solo-founder scale.

The methodology behind the engine is documented at the Build vs Buy Decision Engine methodology page^[4], including the formulas for break-even calculation and the data sources for vendor pricing.

3. Where the decision tree wins: speed and pattern recognition

The decision tree has three structural advantages.

Speed. A decision tree answers a build-vs-buy question in 30 seconds. The engine takes 5-10 minutes to gather inputs and interpret outputs. For the dozens of small decisions a founder makes every week (which logging tool, which form-builder, which feature-flag library), the tree's speed compounds materially.

Pattern recognition. The tree's branches encode wisdom that the engine does not: "If regulated, always buy" is a learned pattern that prevents a category of expensive errors. The engine could produce a contrary verdict on a regulated component if the founder inputs unrealistic hours estimates; the tree refuses to even consider the build path.

Non-technical accessibility. The tree works for founders who cannot estimate engineering hours. The engine requires defensible inputs (build hours, maintenance hours, hourly rate); a non-technical founder cannot reliably produce these, and the engine's output becomes garbage-in-garbage-out. The tree's yes/no questions are answerable from product knowledge alone.

HBR's classical make-or-buy literature^[6] consistently emphasizes the importance of pattern recognition in decisions where the underlying numbers are noisy or unavailable. The tree formalizes the patterns experienced founders use; the engine cannot reproduce them without explicit input.

4. Same scenario, two outputs

Scenario: solo founder evaluating auth, database, and hosting at $100/hour loaded rate.

# build-vs-buy-decision-engine (computed live from /engines/build-vs-buy-decision-engine.js)
Engine input
  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
  components[2].name    = hosting
  components[2].enabled = true
  components[2].time_to_build_hours= 16
  components[2].maintenance_hours_per_month= 3
  components[2].managed_service_cost= 20

Engine output
  components[0].name    = Auth
  components[0].buildCostOneTime= 4000
  components[0].annualMaintenanceCost= 4800
  components[0].annualBuildTotalCost= 8800
  components[0].annualBuyCost= 300
  components[0].breakEvenMonths= null
  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].breakEvenMonths= null
  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).
  components[2].name    = Hosting
  components[2].buildCostOneTime= 1600
  components[2].annualMaintenanceCost= 3600
  components[2].annualBuildTotalCost= 5200
  components[2].annualBuyCost= 240
  components[2].breakEvenMonths= null
  components[2].verdict = BUY
  components[2].reasoning= Buying Hosting at $20/mo costs $240/year but saves 16h upfront + 3h/mo of your time ($5200/year equivalent).
  totalBuildHours       = 76
  totalAnnualBuildCost  = 18400
  totalAnnualBuyCost    = 840
  annualSavings         = 17560
  overallVerdict        = BUY
  insight               = Building everything yourself costs $18400/year in your time. Buying saves 9 hours/month for $70/month. At $100/hour, buying frees up time worth more than the subscription cost.

Engine output: Auth verdict BUY ($8,800 annual build total vs $300 buy), Database verdict BUY ($4,400 vs $300), Hosting verdict BUY ($5,200 vs $240). Total annual savings: $17,560. Total annual build cost: $18,400. Total annual buy cost: $840. Aggregate verdict: BUY.

Tree output: Auth → "regulated/trust-critical?" → yes (passwords, MFA) → BUY. Database → "commodity?" → yes (standard relational DB) → BUY. Hosting → "commodity?" → yes (standard web hosting) → BUY. Aggregate verdict: BUY.

Both reach the same verdict. The engine adds the magnitude ($17,560 of founder time recovered), the tree provides the reasoning ("regulated, commodity, commodity") that explains why the verdict is robust to input variation. Together they produce a stronger decision than either alone: BUY all three, with $17k+ at stake, justified by category rather than by sensitive cost assumptions.

5. Edge cases the engine catches and the tree misses

The engine catches three edge cases the tree's heuristics miss.

• Vendor pricing inversion at scale. A $25/month vendor at 1,000 users becomes $1,200/month at 50,000 users (per-seat). The tree's "is it commodity" question doesn't capture this; the engine, run at projected 12-month-out scale, returns BUILD when the math flips.
• Maintenance load growth. Some components start with 1 hour/month maintenance and grow to 8 hours/month as scale increases. The tree treats maintenance as static; the engine accepts a maintenance-hours input that can be tested at different operational scales.
• Founder hourly value variation. A founder at $50/hour and a founder at $250/hour face different build-vs-buy economics on the same component. The tree gives the same answer to both; the engine returns different break-even months and may flip the verdict for one.

6. Edge cases the tree catches and the engine misses

The tree catches three edge cases the engine misses.

• Regulatory tail. Auth (passwords, MFA, audit trails) has a regulatory tail the engine cannot price. A founder who inputs 40 hours of build effort is excluding the SOC 2 audit work that arrives in year two. The tree's "regulated?" branch refuses to consider build regardless of the math.
• Core differentiation. A component that is part of the product's competitive moat should be built even if the math says buy, because outsourcing differentiation outsources the moat. The engine cannot value moat preservation; the tree's "core differentiation?" branch captures this.
• Single-point-of-failure risk. A vendor whose disappearance would kill the product carries a structural risk the engine cannot quantify. The tree's "30-day migration path?" branch surfaces this risk; the engine's verdict is BUY by default and misses the strategic exposure.

The Bureau of Labor Statistics^[3] reports software developer wages of $140,910 (May 2024 mean), which the engine uses as an hourly-rate anchor. The tree does not need this number to produce a reliable verdict on the regulated-or-not question; the heuristic survives any reasonable hourly rate.

7. The hybrid workflow most solo founders end up using

Experienced solo founders converge on a 3-step hybrid workflow:

1. Run the tree first. 30 seconds per component. Filter out the obvious BUY categories (payments, identity, regulated) and the obvious BUILD categories (your core differentiation, your unique value-add).
2. Run the engine on the residue. For components that survive the tree's filter (genuinely uncertain BUILD-or-BUY questions), input the engine's required data (hours, rate, vendor cost) and read the magnitude.
3. Sanity-check with sensitivity. Vary the inputs ±50% and check that the verdict holds. If the verdict flips on small changes, the decision is sensitive and deserves more thought. If the verdict is robust, ship the decision and move on.

This workflow produces decisions in minutes instead of hours, with the same accuracy as a full engine-only workflow and better robustness than a tree-only workflow. The build vs buy solo founder framework covers the broader workflow, and the three-component build vs buy article walks the engine on auth/database/hosting specifically.

8. Which tool to use when

By question type:

• Small tactical decisions (which logging library, which form-builder): tree only. Speed matters more than precision; the magnitudes are small enough that wrong answers are cheap.
• Major infrastructure decisions (auth, database, hosting, payments): tree first to filter, then engine on the uncertain residue.
• Strategic build/buy decisions at scale ($100k+ annual impact): engine first with multiple scenarios, tree as a sanity check on the categorical reasoning.
• Non-technical founder decisions: tree only. Engine inputs require engineering judgment that non-technical founders cannot reliably provide.
• Migration decisions (replace existing vendor with build): engine, with the existing vendor cost as one input and the new build cost as another. Tree is less informative here because the existing vendor relationship has sunk-cost components.

9. FAQ

What is the difference between the engine and a decision tree? Engine = quantitative output from quantitative input. Tree = qualitative branching from yes/no questions. Engine is more rigorous, tree is faster.

Which is more accurate? The engine when inputs are accurate; the tree when inputs are uncertain or the question has strong categorical answers (regulated → always buy).

Should I use both? Yes. Tree first to filter, engine on the genuinely uncertain residue.

When is the tree better? When you need a 30-second answer, when the founder is non-technical, or when the question has strong categorical answers.