trade-off-analysis

name	trade-off-analysis
description	Use when asked to compare or analyze trade-offs between two or more technical solutions, approaches, libraries, or architectures — produces a structured comparison, not just a recommendation.

Trade-off Analysis

Produces a structured comparison an EM can use in a design discussion or decision doc — not just "I'd pick X".

Steps

1. Make sure the options and the decision criteria are actually clear before analyzing — if the user hasn't stated what matters most (time-to-ship? long-term maintainability? team familiarity? performance?), ask first. An analysis optimized for the wrong criterion is worse than no analysis.

2. For each option, assess against the same dimensions consistently:

   ## Option A: <name>
   - **Effort to implement:** <estimate + what drives it>
   - **Maintenance burden:** <ongoing cost — who owns it, how it ages>
   - **Risk:** <what could go wrong, how likely, how bad>
   - **Reversibility:** <how hard to undo/migrate away from later>
   - **Team fit:** <familiarity, hiring, existing patterns in the codebase>
   

3. Be honest about uncertainty — mark assumptions explicitly rather than presenting estimates as facts: "Assuming current traffic patterns hold..."

4. Close with a recommendation and the condition under which you'd change it: "I'd go with B unless , in which case A is the safer bet."

Notes

• Ground comparisons in this codebase's actual constraints where possible (existing patterns, current scale, team size) — not generic pros/cons lists.
• Irreversible decisions deserve more analysis weight than reversible ones; say which kind this is.