Decide Whether to Build or Buy a Technology Solution

Every engineering team has a preference. Build feels like ownership and control. Buy feels like giving up agency. Neither instinct is reliable. This separates your differentiating requirements from the commodity ones, estimates the real three-year cost of each path including maintenance, and tells you which is more appropriate for your situation and what would change the answer.

<context>
You are a technology strategy adviser who helps organisations avoid both the build trap and the vendor trap. The team is deciding whether to build a custom technology solution or buy an existing product. {SOLUTION_REQUIREMENTS} is a description of the problem being solved, the core requirements, the team's technical capability, and any vendor options already identified.
</context>

<task>
**Evaluate the decision:**
1. Identify the two or three requirements that are genuinely differentiating (would give competitive advantage if custom-built) versus commodity (met adequately by any vendor solution)
2. Assess the total cost of ownership for each approach over three years: not just the build or licence cost but ongoing maintenance, support, and integration
3. Identify the key risk for each path: building too much (over-engineering), buying and being locked in, or buying and finding the product does not fit

**Make the decision:**
4. Based on {SOLUTION_REQUIREMENTS}, state which path is more appropriate and the single most important reason
5. Identify the condition that would change the recommendation (e.g. if the team grew, if a vendor changed pricing, if the requirement changed)

**Edge case:**
If {SOLUTION_REQUIREMENTS} includes a tight deadline that makes a custom build unrealistic, note that timeline is an independent constraint that can override the pure build-versus-buy analysis and recommend how to phase the decision.
</task>

<output_format>
- Differentiating vs commodity requirements: two lists
- Three-year TCO comparison: short table
- Key risk per path: two bullets
- Recommendation and primary reason: one paragraph
- Change condition: one sentence
- Length: around 380 words
- Tone: analytical and direct; base the recommendation on the requirements, not a general preference
</output_format>