Software projects
Compare technical options against project constraints
List the project's constraints first, then judge each option against them one at a time. For every option, record the requirement it supports, what it costs, what evidence you have and what you still don't know. A note like this can be reviewed after the decision.
A text to start with
I'm choosing between [option A], [option B] and [option C] for [what the software must do]. Constraints I know about: [team skills, deadline, budget, existing systems, data volume if known]. Build a comparison note. For each option, list the requirement it supports, the tradeoff, the evidence I've given you and what is still unknown. Do not recommend one yet. Flag any claim that I did not supply.
Example request. Change the details to fit your situation.Technical options comparison
Decision to be made: [ ] Constraints, with source: [ ] Option: [ ] Requirement it supports: [ ] Tradeoff: [ ] Evidence and where it came from: [ ] Ongoing operational work it adds: [ ] Unknown and how to find out: [ ] Claims that are assumptions, not measured: [ ] Person who will run this after launch: [ ] Choice, reason and date: [ ] Repeat the item block as needed.
Claims that need evidence
Performance statements are the usual weak spot. Words like faster, scalable or lightweight need a measurement, a source or a label saying they are assumptions. Check each option for work that continues after launch: hosting, upgrades, monitoring, backups, on-call time and the skills needed to keep it running. Options often look cheap because those costs are missing from the comparison. Also watch for an option that quietly changes a constraint, such as a longer timeline, and for tradeoffs listed only for the options you dislike.
Ask another agent to check the result
Read this options note and challenge every performance or scaling claim that lacks a measurement or source. Then list operational costs the note leaves out, such as upgrades, monitoring, backups and support time. Label each claim as evidence or guess, using only what the note contains.
Turn the note into a decision
Mark each unknown as something you can test, look up or ask someone. Run the cheapest test on the leading option, such as a small prototype against your real data. Share the note with the people who would run the system and ask what it leaves out. Record the choice, the reason and the date, then keep the note with the project.