The Prompt
I am a Senior Product Manager evaluating whether to [build in-house / adopt open-source / license a vendor solution] for [specific component or capability].
Our constraints:
- Team: [number of engineers, their expertise]
- Timeline: [desired delivery window]
- Scale: [number of products / users affected]
- Tech stack: [frameworks, design system context]
- Non-negotiables: [accessibility, compliance, brand consistency, etc.]
Conduct a structured buy vs. build analysis. For each option (build, open-source, vendor), evaluate:
1. **Total Cost of Ownership** over 3 years — include build, maintain, upgrade, and opportunity cost
2. **Time to value** — realistic delivery timeline including integration and adoption
3. **Strategic fit** — does this build platform leverage or create one-off technical debt?
4. **Risk profile** — what are the top 3 failure modes for each option?
5. **Hidden costs** — what do teams typically underestimate in each scenario?
- Structured comparison table (option × dimension)
- A recommended option with a clear rationale
- 3 questions I should pressure-test with my engineering lead before deciding
- One question that would change your recommendation if the answer were different
Why this prompt works
Most buy vs. build conversations stall at surface-level cost comparisons. The hidden costs and pressure-test questions force the AI to surface the uncomfortable truths your team isn't saying out loud — vendor lock-in, migration debt, the engineer who becomes the sole maintainer. The final question ("what would change your recommendation") is a forcing function for intellectual honesty.