WhyChose

Topic: decision log template

Decision Log Template (Free, Copy-Paste)

A decision log is what you want when an ADR feels like too much ceremony. One row per decision, six columns, works for PMs, ops teams, and founders who don't want a /doc/decisions/ folder just yet.

TL;DR

Six columns: Date, Topic, Options Considered, Chose, Rejected, Why. Keep each row to 2–3 sentences per cell. That's the whole template. Works in Airtable, Notion, Linear, Google Sheets, or a single Markdown table. Download as .csv · Download as .md.

The template

Markdown version

| Date       | Topic                      | Options Considered                 | Chose          | Rejected            | Why                                                      |
|------------|----------------------------|------------------------------------|----------------|---------------------|----------------------------------------------------------|
| 2026-02-14 | Primary datastore          | Postgres, MongoDB, DynamoDB        | Postgres 16    | MongoDB, DynamoDB   | Billing needs multi-doc ACID; team owns Postgres.        |
| 2026-02-20 | Billing provider           | Stripe, Paddle, Lemon Squeezy      | Stripe         | Paddle, Lemon       | Stripe Tax covers our EU VAT blockers out of the box.    |
| 2026-03-04 | Frontend framework         | Next.js, Remix, Astro              | Astro          | Next, Remix         | Static-first; we have no SSR requirements yet.           |
| 2026-03-11 | Auth                       | Clerk, Auth0, rolled own           | Clerk          | Auth0, DIY          | Time-to-ship; can replace in year 2 if vendor-locked.    |

CSV version

Date,Topic,Options Considered,Chose,Rejected,Why
2026-02-14,Primary datastore,"Postgres, MongoDB, DynamoDB",Postgres 16,"MongoDB, DynamoDB",Billing needs multi-doc ACID; team owns Postgres.
2026-02-20,Billing provider,"Stripe, Paddle, Lemon Squeezy",Stripe,"Paddle, Lemon",Stripe Tax covers our EU VAT blockers out of the box.

Why only six columns?

Every team that uses a decision log long enough eventually converges on roughly these fields. The temptation is to add more: owner, status, deadline, linked tickets, outcome review date. Don't, at least not until you have 30+ rows and a clear need. The point of a decision log is that it's low-effort enough you'll actually write in it. Every column you add doubles the cognitive cost of a new row and halves the adoption rate.

If you find yourself wanting to attach long rationales, implementation plans, or alternatives-rejected paragraphs, you've graduated to ADR territory — use the Markdown ADR template for those.

Where to store it

How WhyChose helps

If you've been making decisions in ChatGPT or Claude and just not logging them, WhyChose extracts them from your chat export and emits a decision log in exactly this six-column shape. Output formats: .csv, .md, and Notion-importable JSON. Run once a quarter on your chat history and you get 20–60 pre-filled rows to audit — the ones you miss are the ones where the decision wasn't explicit in the chat anyway. The same extractor is open-source if you'd rather self-host.

Get early access

Related questions

What's the difference between a decision log and an ADR?

A decision log is a row per decision, optimized for breadth and low friction. An ADR is a file per decision, optimized for depth and auditability. Teams often run both: ADRs for durable architecture calls, decision logs for product/ops/pricing choices. See the ADR vs DDR explainer.

Should the decision log be public?

Internal to the company, yes. Public, usually not — decision rationales reveal roadmap and internal priorities. If you want to share externally, pick specific rows and turn them into blog posts or changelog entries.

How do I keep the log from going stale?

Time-box a 10-minute review at the end of every sprint or every two weeks. Add any decisions from the period. Don't try to catch up months at a time — you'll miss half and abandon the practice. If you've already missed months, extract from your chat history instead of trying to remember.

Further reading