A decision log is the second most underrated project artefact, right after the risk register. Six months from now, someone — maybe you — will ask "wait, why did we do it that way?" Without a decision log, the answer is a Slack-archaeology expedition that ends in a guess. With one, the answer is a row.
This free decision log template is built for teams who've been burned by undocumented decisions and want to stop it happening again. Edit inline, add rows in one click, export to CSV when you need to share. Persists in your browser between sessions. No signup, no account, no syncing — just a single-purpose table that does one job well.
The columns are deliberately shaped to force good decision hygiene:
- Date — when the decision was made. Useful when you're scanning for "what did we decide in Q1?"
- Decision — the actual call, in one plain sentence. "Use Postgres, not Mongo." Not "Discussed database options."
- Context — what was happening that made this decision necessary. The future-you reading this in a year needs this paragraph more than you realise.
- Alternatives considered — list what you *didn't* pick. This is the field that prevents Groundhog Day arguments six months later when someone proposes the alternative you already rejected.
- Decided by — the person or group with the call. RFC author, RACI accountable, whatever — name it.
- Status — Proposed, Decided, Implemented, Revisited, Reversed. Decisions aren't immutable; mark when one gets revisited.
The seeded examples show the shape: a technical architecture decision, a hiring decision, a process decision, a vendor decision. Replace with your own.
Why this matters more than people think: the cost of re-litigating a decision is 4-6x the cost of making it the first time. Once a team has burned three meetings re-debating whether to use REST or GraphQL, the decision log pays for itself. Once a new hire onboards and reads the log instead of asking five people, it pays for itself again.
When to log a decision: anything that involves a tradeoff that wasn't obvious, any vendor or technology choice, anything that locks you in for 6+ months, anything you'd want a new team member to understand context for. Daily operational calls don't need logging — strategic ones do.
If you want this hooked into your actual project work (so a logged decision can spawn the implementation tasks automatically), that's what the main LemTask app does. For a standalone decision log you can keep in a tab and share via CSV, this is enough.