Vendor Lock-In vs Best-of-Breed Tooling Prompt Template

This prompt is designed for the moment a team proposes adopting a managed service, all-in-one platform, or proprietary toolchain without a clear, written analysis of the long-term switching costs. The job-to-be-done is not to make the decision for you, but to force an explicit, structured comparison that surfaces hidden assumptions. Use it during an architecture review, before signing a contract, or when a vendor's 'fast time-to-value' narrative is drowning out concerns about future flexibility. The ideal user is an engineering lead, architect, or CTO who needs a decision memo that can be shared with stakeholders, not a black-box recommendation.

You should not use this prompt when the decision is trivial, the tool is a commodity with zero switching cost, or you are comparing two nearly identical open-source libraries. It is also inappropriate for purely cost-driven decisions where a simple Total Cost of Ownership (TCO) spreadsheet suffices. The prompt's value lies in its multi-dimensional analysis: feature depth, integration burden, pricing predictability, migration cost, long-term flexibility, and operational maturity. If you cannot provide concrete context for at least four of these dimensions, the output will be speculative and low-value. For high-risk or high-spend decisions, always pair the model's output with a human review step to validate claims about vendor roadmaps, pricing models, and integration complexity against primary sources.

To get a useful memo, you must provide the prompt with specific, grounded context. This includes the proposed vendor solution, the best-of-breed alternative, your current stack, and any non-negotiable constraints like compliance requirements or existing team skills. The prompt template uses placeholders like [VENDOR_SOLUTION] and [BEST_OF_BREED_ALTERNATIVE] to make this explicit. After generating the memo, treat it as a draft for discussion. The next step is to pressure-test the 'Unstated Switching Costs' section with your team, as this is where the model will identify risks you haven't yet documented. Avoid the temptation to use the output as a final scorecard; its purpose is to improve the quality of your debate, not to end it.

This prompt template is designed to produce a rigorous, dimension-by-dimension comparison memo. It forces the model to evaluate a specific managed service against a concrete alternative composed of open-source or specialized tools, rather than generating generic pros and cons. The output is intended to feed directly into an Architecture Decision Record (ADR) or a technical due diligence package.

textCopy
You are a principal architect evaluating a critical technology decision. Your task is to produce a structured trade-off analysis memo comparing a managed vendor platform against a best-of-breed integrated stack for a specific use case.

## Input Context
- **Business Objective:** [BUSINESS_OBJECTIVE]
- **Functional Requirements:** [FUNCTIONAL_REQUIREMENTS]
- **Non-Functional Constraints:** [NON_FUNCTIONAL_CONSTRAINTS]
- **Team Profile:** [TEAM_PROFILE]
- **Current Tech Stack:** [CURRENT_TECH_STACK]

## Options to Compare
1.  **Option A: Managed Vendor Platform**
    - **Vendor & Product:** [VENDOR_PLATFORM_NAME]
    - **Key Capabilities:** [VENDOR_CAPABILITIES]
2.  **Option B: Best-of-Breed Integrated Stack**
    - **Component Tools:** [BEST_OF_BREED_TOOLS]
    - **Integration Strategy:** [INTEGRATION_STRATEGY]

## Analysis Dimensions
For each dimension below, provide a direct comparison, a risk assessment, and a preliminary score (1-5, where 5 is most favorable).

1.  **Feature Depth & Fit:** Does one option provide a decisive functional advantage for our specific requirements?
2.  **Total Cost of Ownership (TCO):** Compare license/subscription fees, infrastructure costs, and the fully-loaded engineering time required to build, maintain, and operate each option over 3 years.
3.  **Integration & Migration Burden:** Quantify the effort to integrate with [CURRENT_TECH_STACK] and the estimated switching cost to leave each option in the future.
4.  **Operational Overhead:** Compare the day-2 operational burden, including monitoring, patching, scaling, and on-call complexity.
5.  **Team Capability & Velocity:** Assess the fit with [TEAM_PROFILE]'s current skills and the impact on feature delivery velocity.
6.  **Pricing Predictability & Licensing Risk:** Evaluate the risk of unexpected cost increases, audit exposure, or unfavorable license changes.
7.  **Long-Term Flexibility & Control:** Analyze the risk of architectural lock-in, the ability to customize behavior, and control over the upgrade roadmap.

## Output Schema
Return a valid JSON object with the following structure. Do not include markdown fences or commentary outside the JSON.
{
  "executive_summary": "A 3-sentence summary stating the primary trade-off and a clear recommendation.",
  "comparison_matrix": [
    {
      "dimension": "string",
      "vendor_platform_assessment": "string",
      "best_of_breed_assessment": "string",
      "vendor_score": number,
      "best_of_breed_score": number,
      "key_risk": "string"
    }
  ],
  "unstated_assumptions": ["List assumptions you made to complete this analysis."],
  "switching_cost_estimate": {
    "vendor_lock_in_risk": "high|medium|low",
    "estimated_migration_effort_months": number,
    "primary_cost_driver": "string"
  },
  "recommended_next_steps": ["A list of concrete actions, such as a PoC scope or a specific vendor question to resolve."]
}

## Constraints
- Base your analysis strictly on the provided context. Do not invent requirements.
- If a dimension cannot be evaluated due to missing information, flag it as an "Unresolved" risk instead of guessing.
- Explicitly separate facts from architectural opinion.

To adapt this template, replace every square-bracket placeholder with concrete data from your discovery process. The [BEST_OF_BREED_TOOLS] placeholder should contain a specific list of components (e.g., 'Apache Kafka + Flink on Kubernetes'), not a vague category. Before executing the prompt in a production harness, validate that the JSON output strictly conforms to the schema using a JSON Schema validator. For high-stakes procurement decisions, always route the final executive_summary and switching_cost_estimate for human review before archiving the output as a decision record.

This prompt is designed to be integrated into an architecture decision workflow, not used as a one-off chat. The primary integration point is an Architecture Review Board (ARB) or Technical Design Review process where a proposal document, RFC, or architecture decision record (ADR) draft is submitted. The prompt should be called programmatically with the proposal text, a list of identified vendor dependencies, and any known organizational constraints. The output is a structured trade-off memo that becomes evidence in the decision record, not the decision itself.

Wire the prompt into an API endpoint or a CI/CD pipeline stage that triggers on ADR pull requests. The application layer should validate the model's output against the expected JSON schema before accepting it. Key validation checks include: all required dimensions (migration cost, feature depth, integration burden, pricing predictability, long-term flexibility) are present with non-empty assessments; each assessment includes an explicit confidence level; and the unstated_switching_costs array is populated or explicitly declared empty with a reason. If validation fails, implement a single retry with the validation errors injected into the [CONSTRAINTS] field of the retry request. After two failures, escalate to a human reviewer via the team's existing review queue (e.g., Jira, Linear, or a Slack channel) with the raw proposal, the failed outputs, and the validation error log attached.

For model choice, use a model with strong reasoning and structured output capabilities (e.g., Claude 3.5 Sonnet, GPT-4o) rather than a smaller or faster model. The task requires multi-dimensional comparison and the detection of implicit assumptions, which smaller models often flatten into generic pros-and-cons lists. Set temperature to 0.2 or lower to reduce variance in the trade-off assessments. If your organization maintains a vector store of past ADRs and post-implementation reviews, retrieve the top three most similar decisions and inject them into the [CONTEXT] field as reference points for recurring lock-in patterns. Log every prompt invocation, the raw output, validation results, and the final accepted or escalated outcome to your observability platform for audit and prompt drift detection.

Do not treat the model's output as the final decision. The prompt produces a structured analysis that must be reviewed by the responsible architect or engineering lead before the ADR is accepted. The highest-risk failure mode is the model missing a switching cost that is obvious to an engineer familiar with the specific vendor's ecosystem (e.g., data egress fees, proprietary API behaviors, or operational tooling lock-in). Always require a human to sign off on the unstated_switching_costs section and to confirm that the confidence levels match their own assessment. The prompt is a forcing function for thoroughness, not a replacement for engineering judgment.