Build vs Buy Decision Memo Prompt Template

This prompt is designed for engineering leads, architects, and technical decision-makers who must produce a documented, defensible analysis comparing building a custom solution against purchasing a third-party product. The core job-to-be-done is surfacing hidden assumptions, quantifying trade-offs, and neutralizing advocacy bias before committing significant organizational resources. The ideal user has already gathered preliminary data on internal team capacity, rough cost estimates, and the strategic importance of the capability in question. The prompt is not a replacement for human judgment; it is a structured thinking tool that produces a memo suitable for feeding into an Architecture Decision Record (ADR) or an executive review packet.

Use this prompt when the decision involves multi-year cost, maintenance, and strategic consequences. It is most effective when you can provide concrete context for the [BUILD_ESTIMATE], [BUY_OPTIONS], and [STRATEGIC_CONTEXT] placeholders. The prompt forces a comparison across total cost of ownership (TCO), time-to-market, maintenance burden, team capability fit, and strategic risk. It is particularly valuable when a team or stakeholder is already leaning strongly in one direction, as the structured format and explicit bias checks help ensure the final memo is evidence-based rather than advocacy-driven. You should not use this prompt for trivial tool selection, decisions with a clear and uncontested winner, or when you lack any internal data to ground the analysis.

Before executing this prompt, ensure you have completed the prerequisite data gathering. The prompt will fail gracefully if given vague inputs, but its output will be superficial. The resulting memo is a starting point for a human-led review, not a final decree. After generating the memo, you should validate its findings against your own data, challenge its identified risks, and use it to frame a deliberate conversation with stakeholders. Do not use the output to automate the decision itself.

The prompt template below is designed to be copied directly into your AI harness. It forces the model into the role of a neutral systems architect, not an advocate for either option. The output is a structured memo that compares building a custom solution against purchasing a third-party product across dimensions that matter to engineering leaders: total cost of ownership, time-to-market, maintenance burden, team capability fit, and strategic risk. Replace every square-bracket placeholder with your specific context before sending the prompt to the model. The more concrete your inputs, the less room the model has to invent assumptions.

textCopy
You are a neutral systems architect with no advocacy bias toward building or buying. Your task is to produce a structured Build vs Buy Decision Memo that helps an engineering leadership team make an informed choice.

## Context
- Problem to solve: [PROBLEM_DESCRIPTION]
- Current system landscape: [CURRENT_ARCHITECTURE_CONTEXT]
- Team size and composition: [TEAM_SIZE_AND_SKILLS]
- Budget constraints: [BUDGET_CONSTRAINTS]
- Timeline pressure: [TIMELINE_REQUIREMENTS]
- Strategic importance: [STRATEGIC_IMPORTANCE]

## Options to Evaluate
- Build option: [BUILD_OPTION_DESCRIPTION]
- Buy option(s): [BUY_OPTION_DESCRIPTIONS]

## Output Schema
Produce a memo with the following sections. Use the exact headings provided.

### Executive Summary
One paragraph that states the recommendation and the single most important reason for it. If the evidence is evenly balanced, say so explicitly.

### Option Summaries
For each option, provide:
- Description (2-3 sentences)
- Key assumptions (bullet list)
- Primary risk (one sentence)

### Trade-Off Matrix
A markdown table with these rows:
- Total Cost of Ownership (3-year)
- Time to First Value
- Maintenance Burden
- Team Capability Fit
- Customization Flexibility
- Vendor Lock-In Risk
- Security and Compliance Fit
- Strategic Control

For each row, include a column for each option with a rating (Low / Medium / High) and a one-sentence justification.

### Hidden Assumptions
List 3-5 assumptions that, if wrong, would change the recommendation. For each assumption, state which option it favors and how to validate it.

### Risk Register
A table with columns: Risk, Likelihood (Low/Medium/High), Impact (Low/Medium/High), Mitigation. Include at least 4 risks.

### Recommendation
State the recommended option. Include:
- Primary rationale (2-3 sentences)
- Conditions that would change the recommendation
- Suggested phased approach or proof-of-concept next step

## Constraints
- Do not invent vendor names, pricing, or features unless provided in the input.
- If information is missing, flag it in the Hidden Assumptions section rather than guessing.
- Use quantitative ranges (e.g., "$50K-$80K/year") only when input data supports them. Otherwise use qualitative comparisons.
- Do not advocate. Present trade-offs neutrally.
- If the decision is genuinely too close to call with available information, recommend a low-cost experiment to gather the missing data.

Adaptation guidance: The placeholder [PROBLEM_DESCRIPTION] should include enough detail that the model understands scope, scale, and constraints. Avoid vague inputs like "we need a CRM" — instead describe the specific workflows, integration points, user count, and data volumes. The [BUY_OPTION_DESCRIPTIONS] placeholder can include one or more vendor or product options; if you have specific products in mind, name them and provide their known capabilities and limitations. If you are evaluating multiple buy options against a single build option, list each buy option separately. The output schema is designed to be parseable: the markdown table in the Trade-Off Matrix section can be extracted programmatically for downstream tooling or dashboards. Before deploying this prompt in a production workflow, run it against 3-5 historical build-vs-buy decisions where you know the outcome, and check whether the model's recommendation and reasoning align with what your team actually decided and why.

The Build vs Buy Decision Memo prompt is designed to be called from an application layer that supplies structured inputs and validates the structured output. Do not expose this prompt directly in a free-text chat interface. The application should collect the required inputs—[OPTION_A], [OPTION_B], [CONTEXT], [CONSTRAINTS], and [DIMENSIONS]—from a form, a prior analysis step, or a configuration file. The prompt is then assembled by injecting these values into the template. This separation ensures that the model receives a complete, consistent request every time and that missing fields are caught before the API call.

For production use, implement a validation harness around the model response. The prompt instructs the model to return a JSON object matching a specific schema. Your application must parse this JSON and validate it against the expected structure: check that all requested dimensions are present, that scores are within the defined range, that the assumptions array is populated, and that the recommendation field is not empty. If validation fails, implement a retry loop (maximum 2 retries) that sends the original prompt plus the validation error message back to the model, instructing it to correct the output. Log every validation failure and retry attempt for observability. For high-stakes build vs buy decisions, the final memo should always be routed to a human review queue where an architect or engineering lead can confirm the analysis, challenge assumptions, and add context before the memo is finalized.

Choose a model with strong reasoning and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate starting points. If using a model that supports native JSON mode or structured output constraints, enable it to reduce malformed responses. For teams with strict data residency requirements, the prompt works with locally hosted models like Llama 3.1 70B, but expect more frequent validation failures and budget additional retries. The prompt does not require tool use or retrieval-augmented generation (RAG) in its basic form, but you can extend it by providing a [CONTEXT] field populated from internal documents, prior ADRs, or vendor research. When doing so, ensure the context is summarized and relevant to avoid exceeding context windows.

Monitor for advocacy bias as a failure mode. The model may produce a recommendation that mirrors the framing of the input options. To mitigate this, the application can run a secondary eval prompt that scores the output for balanced treatment of both options. If the eval detects a skew greater than a defined threshold, flag the memo for human review. Also track the distribution of build vs buy recommendations over time to detect systemic drift. Finally, version your prompt template and store each generated memo with the prompt version, model identifier, and input hash to enable debugging and auditability when decisions are revisited months later.