ADR Build vs Buy Decision Prompt

This prompt is for technical decision makers and architects evaluating whether to build a capability in-house or adopt an external solution. Use it when you need a structured comparison across cost, control, maintenance burden, team capability, and strategic fit before committing engineering resources. The prompt is designed to produce a draft Architecture Decision Record section that can be reviewed, debated, and finalized by humans. It is not a replacement for vendor due diligence, security review, or legal approval.

Run this prompt early in the decision process, before significant procurement or prototyping effort has been spent, so the output can shape the evaluation criteria rather than justify a decision already made. The prompt requires concrete inputs: a clear description of the capability needed, known constraints (budget, timeline, compliance, team skills), and at least one build option and one buy option to compare. Without these inputs, the model will generate plausible-sounding but untethered analysis that wastes review cycles. If you haven't identified at least one credible external solution or internal approach, run the Decision Options Enumeration Prompt first to generate alternatives before invoking this comparison.

Do not use this prompt when the decision is purely about vendor selection among multiple buy options—that requires a different evaluation structure focused on feature matrices, SLAs, and procurement criteria. Do not use it when the build option is a strawman designed to make a preferred vendor look better; the prompt includes bias checks for NIH syndrome and vendor lock-in risk, but it cannot detect bad-faith inputs. Do not use it when the capability is trivial (a single library import or SaaS signup with no architectural implications) or when the decision has already been made and you're seeking post-hoc justification. The output is a draft for human review, not a final decision document. Always validate cost estimates, vendor claims, and team capacity assumptions independently before the ADR is accepted.

This prompt template is the core engine for generating a Build vs. Buy Architecture Decision Record. It is designed to be copied directly into your prompt layer, whether that's a Python script, a LangChain template, or a direct API call. The template forces a structured comparison by requiring the model to evaluate options against a fixed set of criteria—cost, control, maintenance, team capability, and strategic fit—before making a recommendation. This structure prevents the model from defaulting to a superficial preference and ensures the output is a traceable, defensible document, not just a paragraph of advice.

textCopy
You are a senior software architect producing an Architecture Decision Record (ADR) for a Build vs. Buy decision.

Your task is to analyze the provided context and produce a structured ADR in Markdown. You must evaluate the decision against the following weighted criteria: Total Cost of Ownership (25%), Strategic Control and Differentiation (25%), Maintenance and Operational Burden (20%), Team Capability and Learning Curve (15%), and Integration and Security Fit (15%).

Before writing the final ADR, you must perform a bias check for "Not Invented Here" (NIH) syndrome and vendor lock-in risk. Explicitly state if either bias is detected and how it was mitigated in the analysis.

## INPUTS
- [CAPABILITY_DESCRIPTION]
- [PROBLEM_CONTEXT]
- [BUSINESS_CONSTRAINTS]
- [TEAM_SKILLS_AND_CAPACITY]
- [BUILD_OPTION_DETAILS]
- [BUY_OPTION_DETAILS]
- [VENDOR_EVIDENCE]

## OUTPUT_SCHEMA
You must output a single JSON object with the following structure. Do not include any text outside the JSON object.
{
  "title": "ADR: Build vs. Buy for [Capability Name]",
  "status": "proposed",
  "context": "A concise summary of the problem and business drivers.",
  "decision": "The final decision: 'Build', 'Buy', or 'Hybrid'.",
  "options_assessment": {
    "build": {
      "description": "A brief description of the in-house build approach.",
      "pros": ["string"],
      "cons": ["string"]
    },
    "buy": {
      "description": "A brief description of the external solution.",
      "pros": ["string"],
      "cons": ["string"]
    },
    "hybrid": {
      "description": "A brief description of a potential hybrid approach, if applicable.",
      "pros": ["string"],
      "cons": ["string"]
    }
  },
  "weighted_evaluation": {
    "total_cost_of_ownership": {"weight": 25, "build_score": 0, "buy_score": 0, "rationale": "string"},
    "strategic_control": {"weight": 25, "build_score": 0, "buy_score": 0, "rationale": "string"},
    "maintenance_burden": {"weight": 20, "build_score": 0, "buy_score": 0, "rationale": "string"},
    "team_capability": {"weight": 15, "build_score": 0, "buy_score": 0, "rationale": "string"},
    "integration_security": {"weight": 15, "build_score": 0, "buy_score": 0, "rationale": "string"}
  },
  "bias_check": {
    "nih_syndrome_detected": true,
    "nih_mitigation": "string",
    "vendor_lockin_risk": "low",
    "lockin_mitigation": "string"
  },
  "risks": ["A list of key risks associated with the chosen decision."],
  "consequences": "What becomes easier and what becomes harder if this decision is accepted."
}

## CONSTRAINTS
- Scores must be integers from 1 to 10.
- The "rationale" fields must cite specific evidence from the [VENDOR_EVIDENCE] or [TEAM_SKILLS_AND_CAPACITY] inputs.
- If a "Hybrid" option is not applicable, set its description to an empty string and its pros/cons to empty arrays.
- The "vendor_lockin_risk" field must be one of: "low", "medium", "high".

To adapt this template, replace each square-bracket placeholder with data from your application. The [VENDOR_EVIDENCE] field is critical for grounding; it should contain raw text from documentation, pricing pages, or security whitepapers, not just a vendor name. This allows the model to cite specific evidence in its rationale, which is essential for a defensible ADR. If you have no evidence, the prompt will still run, but the output's quality and trustworthiness will degrade significantly. For high-stakes decisions, always populate this field with real data and plan for a human review of the generated ADR before it is accepted.

The Build vs Buy prompt is not a one-shot chatbot query. It belongs inside a structured decision workflow where inputs are gathered from multiple sources—cost estimates, team capability surveys, vendor documentation, and strategic context—before the prompt is assembled. The harness should collect these inputs into a typed object, validate that required fields are present (at minimum: [CAPABILITY_DESCRIPTION], [STRATEGIC_CONTEXT], and at least one option in each of [BUILD_OPTIONS] and [BUY_OPTIONS]), and only then render the prompt template. Missing or incomplete inputs should block execution and return a specific error to the user, not silently produce a weak ADR.

After the model returns a response, the harness must validate the output against the expected ADR schema before showing it to a reviewer. At minimum, check that the response contains the required sections (Context, Decision, Options Considered, Trade-off Analysis, Rationale, Consequences), that the Decision field selects exactly one option, and that the Trade-off Analysis includes all dimensions specified in [EVALUATION_CRITERIA]. If validation fails, retry once with the validation errors appended to the prompt as [REPAIR_INSTRUCTIONS]. If the second attempt also fails, surface the partial output with error markers and require human completion. For high-stakes decisions—those tagged with [RISK_LEVEL]='high' or involving budget above a configured threshold—the harness should route the validated ADR to a human review queue and block downstream automation until approval is recorded.

Model choice matters here. Use a model with strong reasoning and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Enable structured output mode or JSON mode with the ADR schema passed as the response format. Log every prompt version, input hash, raw response, validation result, and reviewer action. This audit trail is essential because build-vs-buy decisions are frequently revisited when costs change, vendors evolve, or internal capability grows. Wire the harness to store completed ADRs in a versioned repository with the decision date, author, reviewer, and expiration date if the decision should be re-evaluated periodically. Do not use this prompt inside a fully automated pipeline that acts on the decision without human review—the prompt produces a recommendation, not an authorization.