A solo product decision log needs a review trigger

A solo product decision log should not read like a diary. It should let a future maintainer see what was chosen, what was rejected, and what would make the decision change.

The useful unit is small: one decision, one constraint, one consequence.

For an indie web product, this matters most around choices that feel obvious in the moment: using one AI model as the default, adding a search route, changing a pricing page, removing a feature, or renaming a public concept. These choices become expensive later when the reason is scattered across chats, issues, and commits.

A good entry usually needs four lines, not a template wall.

Decision: what changed.
Constraint: what made this choice necessary now.
Tradeoff: what became worse or remained unresolved.
Review trigger: what evidence would reopen the decision.

Example: “Use one default model for routine support drafts. Constraint: support macros need consistent tone. Tradeoff: specialized coding questions may need routing. Review trigger: correction passes rise above two per answer for a week.”

The review trigger is the part people skip. Without it, the log becomes a museum. With it, the log becomes a lightweight operating system for future product changes.

A solo product decision log needs a review trigger

// COMMENTS

ON THIS PAGE