The Build vs Buy Decision Framer: Turn a Make-or-Buy Debate Into a Structured Recommendation
Why this prompt matters
Teams that skip a structured build-vs-buy analysis tend to decide based on whoever argued loudest in the meeting, not the economics. Internal “we'll build it ourselves” projects routinely blow past their original estimate — a tool budgeted at two engineer-months frequently consumes eight to twelve once maintenance, edge cases, and feature-parity creep set in, while teams that buy without evaluating lock-in risk end up paying three to five times list price by year three once usage scales past the vendor's volume-pricing tiers.
What we use it for
A 40-person SaaS company's engineering team is split on whether to build an in-house customer analytics dashboard or buy Mixpanel or Amplitude. The VP of Engineering wants to build it as a portfolio differentiator; the CFO wants to buy because the budget review is in three days and nobody has actually run the numbers.
Prompt
Act as a senior strategy consultant who has advised on more than 50 build-vs-buy decisions for mid-size technology and operations teams. You are skeptical of both "we can build it cheaper" and "just buy it, don't reinvent the wheel" as unexamined defaults. Context: - Capability or system in question: [E.G., A CUSTOMER ANALYTICS DASHBOARD] - Our team: [TEAM SIZE AND RELEVANT SKILLS] - Available vendor options: [LIST 1-3 CANDIDATE VENDORS OR PRODUCTS, WITH ROUGH PRICING IF KNOWN] - In-house estimate: [ROUGH ENGINEERING TIME/COST ESTIMATE TO BUILD, IF YOU HAVE ONE] - Timeline pressure: [WHEN DOES THIS NEED TO BE LIVE] - Strategic context: [IS THIS CAPABILITY CORE TO OUR COMPETITIVE ADVANTAGE, OR COMMODITY INFRASTRUCTURE] Task: Produce a structured, numbers-based recommendation on whether to build this in-house or buy an existing solution. Think step by step: first estimate the three-year total cost of ownership for each path, then score strategic fit, then analyze the risks specific to each path, and only then commit to a recommendation. Constraints: - Do not default to a hedge like "it depends" — commit to one recommendation. - Do not use the words "synergy," "leverage," or "best-in-class." - Every cost figure must include an explicit assumption (e.g., engineer-years assumed, loaded cost per engineer, vendor pricing tier). - If you do not have enough information to estimate a cost, say so explicitly and flag it as a gap rather than guessing silently. - State the specific condition under which your recommendation would flip (e.g., "if in-house headcount available exceeds X, build becomes competitive"). Output format: 1. Decision Summary (2-3 sentences, the recommendation stated plainly) 2. Three-Year TCO Comparison (build vs buy, with assumptions listed) 3. Strategic Fit Score (1-5 for each path, with one-sentence reasoning) 4. Risk Analysis (top 2 risks of building, top 2 risks of buying) 5. The Flip Condition (what would have to change for the recommendation to reverse)
Result
1. Decision Summary
Buy. For a customer analytics dashboard with 2-3 mature vendor options already covering 90% of the required feature set, building in-house consumes engineering capacity this team cannot spare and does not create defensible differentiation. Recommendation: license Amplitude's Growth plan and redirect the two engineers who would have built this toward the core product roadmap.
2. Three-Year TCO Comparison
Build: Assuming 2 engineers at a fully loaded cost of $180,000/year each for an estimated 4 months of initial build (0.67 engineer-years), plus an ongoing 20% maintenance tax in years 2-3 (0.27 engineer-years/year) for bug fixes, new event types, and dashboard requests — total 3-year cost: approximately $324,000 in engineering time alone, before infrastructure.
Buy: Amplitude Growth plan at an estimated $4,000/month for this team's monthly tracked-user volume, scaling to an estimated $6,500/month by year 3 as usage grows — total 3-year cost: approximately $187,000, inclusive of onboarding.
Gap flagged: vendor pricing is a rough estimate based on published tiers; get a direct quote before finalizing, since enterprise discounts could shift this by 15-20%.
3. Strategic Fit Score
Build: 2/5 — analytics tooling is not a product differentiator customers pay for; the two engineers are more valuable on the core roadmap.
Buy: 4/5 — frees the team entirely for differentiating work, at the cost of some customization limits.
4. Risk Analysis
Building: (1) Estimate creep — dashboards accumulate "just one more metric" requests indefinitely. (2) Opportunity cost — two engineers off the core roadmap for 4+ months during a competitive window.
Buying: (1) Data residency — confirm Amplitude's data handling meets any compliance requirements before committing. (2) Pricing lock-in — renegotiate before auto-renewal once usage triples, or the per-seat cost curve becomes unfavorable.
5. The Flip Condition
If this team had a dedicated, already-staffed data platform engineer with spare capacity (i.e., the build cost were not competing with the core roadmap), the calculus would flip toward building — the 3-year cost gap narrows significantly once the opportunity cost of pulling engineers off other work is removed from the estimate.
Most build-vs-buy debates don't actually get decided on the numbers. They get decided by whoever has more political capital in the room — the engineering lead who wants to build something impressive, or the finance lead who wants the line item gone. This prompt forces the analysis to happen before the opinion does.
The structure is deliberate. It opens with a role that explicitly distrusts both default positions — "build it cheaper" and "don't reinvent the wheel" — because both are reflexes, not conclusions. An AI model (or a person) that starts neutral is far less likely to rationalize backward from whichever answer sounds better in the meeting.
The context block asks for the inputs that actually drive the decision: team skills, vendor options with real pricing, a rough build estimate, timeline pressure, and — critically — whether the capability is strategically core or just commodity infrastructure. Most teams skip that last question entirely and treat every internal tool as if it might become a competitive advantage. It almost never is.
The task instruction sequences the reasoning on purpose: cost first, then strategic fit, then risk, then recommendation. Reversing that order is how teams end up justifying a gut call with selectively chosen numbers. By making the model estimate the three-year total cost of ownership before it's allowed to recommend anything, you remove the temptation to reverse-engineer a number that supports a pre-existing preference.
The constraints section does three specific jobs. Banning hedge language ("it depends") forces a committed answer instead of a non-answer dressed up as nuance. Requiring an explicit assumption behind every cost figure means you can actually audit the math afterward — if someone disagrees with the $180,000 loaded engineer cost, they can argue with that number specifically instead of rejecting the whole analysis. And demanding the flip condition at the end is the most underused part of any decision framework: it tells you exactly what new information would change the recommendation, so you know what to watch for instead of re-running the whole debate every quarter.
Where this earns its place on a weekly-reuse list: any team evaluating a recurring SaaS renewal, a new internal tool request, or an infrastructure component can run the same five-section structure and get a comparable, auditable answer each time — rather than a fresh ad hoc argument with different people weighing in differently depending on who's in the room that week.
Takeaway: before your next build-vs-buy meeting, run this prompt with your actual numbers 24 hours in advance, bring the Flip Condition into the room explicitly, and make the debate about whether that condition holds — not about who argues better.