How do I choose a technical approach without guessing?
The cost of picking wrong is usually not the decision itself. It is discovering you were wrong and cannot get out. Find the irreversible parts first.
How to do it
Compare the options on the same dimensions
Give option A, option B, and your constraints (what the team knows, the current stack, the deadline) to 'Choosing Between Two Options'. Ask for four comparison dimensions and why those four, the worst case for each, the conditions under which each wins, and a clear recommendation for your situation. Do not accept 'it depends'.
Mark which decisions cannot be undone
Paste the plan into 'The Most Expensive Irreversible Part'. Label each decision reversible, reversible at a cost, or irreversible. For the irreversible ones, spell out whether the cost of undoing is money, time, relationships, or opportunity. Identify which decisions can be split into a smaller reversible first step, and ask for an execution order. Slow down on those; the rest can move.
Assume it failed and work backwards
Use 'Pre-Mortem' and assume the approach failed completely six months from now. Have it list the five most likely reasons by probability, the early signal for each today, which ones can be prevented now, and the single thing to do to reduce the chance of failure. Each early signal should be something you can put into monitoring or a review checklist.
Check whether the cost is systematically low
Give the total cost and timeline to 'Is the Cost Underestimated?'. Ask only whether the estimate is biased low: missed communication, migration, rework, training, compliance, maintenance, and opportunity cost. Require an order of magnitude and a basis for each, separate one-off from recurring costs and annualize the latter, and end with a conservative and a worst-case number. This step does not judge whether the project is worth doing.
Decide when to stop before you start
Finally, use 'Set Exit Conditions Up Front' to define three to five observable signals, each with a checkpoint, a threshold, and a person who decides. Distinguish 'temporarily rough' from 'wrong direction', explain how to preserve what you have invested when you exit, and ask for a middle option that shrinks scope instead of stopping. Put the result in the project document, not just the chat.
Prompts used
FAQ
Should I just let AI make the technical decision?
Let it make a clear recommendation, but only after you state the constraints: what the team knows, what the current system looks like, and how bad a worst case you can absorb. Its recommendation follows those constraints; it does not include your company's history or internal politics.
How do I tell if an approach is over-engineered?
Check whether it solves a present problem or an imagined one. Step 2 pulls out the parts that can be split into a reversible first version. If that smaller version is enough, the full design is over-engineering.
What if we pick wrong?
That is what step 5 is for: define observable exit signals and a decision owner in advance, and stop when they trigger instead of waiting until so much is invested that nobody dares to stop it. Exit conditions written after the fact are usually too late.