How to Use Decision Logs as a Founder

A decision log is a running record of the meaningful choices you make as a founder, written down before you know how they turn out. Each entry captures the decision, the context, the options you weighed, your reasoning, and what you expected to happen. It exists so future-you can grade past-you honestly instead of rewriting the story.

I keep one because I run several products alone and have no team to remember why a call was made. There is no standup where someone says “we tried that in March and here is what happened.” If I do not write down why I picked Relay over Mercury, or why I shipped a feature flag instead of a full rewrite, that reasoning is gone in a month. My memory will happily invent a cleaner version of it.

This post is the practical version of that habit: what a decision log is, the exact fields I capture per entry, how to tell reversible decisions from irreversible ones, and how to review old entries so your judgment actually improves. If you already run a weekly review, a decision log is its long-memory companion, and it fits cleanly inside a solo founder operating system alongside the AI workflows you already use. It is one of the cheapest Distribution and founder-operations habits you can start today.

Key takeaways

• A decision log records why you chose something before the outcome is known, which is the only thing that defends against hindsight bias.
• Each entry captures eight fields: date, decision, context, options, reasoning, expected outcome, confidence, and review date.
• Sort decisions into reversible (two-way door) and irreversible (one-way door); spend your deliberation budget on the one-way doors.
• The log only pays off if you review it: read old reasoning against real outcomes to calibrate your judgment over time.
• Keep it in a plain text or Markdown file with almost zero friction, or the habit dies in the first week.

A decision log is a record of reasoning, not outcomes

The single most important property of a decision log is timing. You write the entry before you know the result. That one constraint separates it from every other note you keep, and it is the reason it works.

Here is the problem it solves. When a decision turns out well, your brain quietly rewrites the past so you “always knew” it would work. When it turns out badly, it rewrites the past so the failure was “obvious in hindsight.” Psychologists call this hindsight bias, the tendency to see past events as more predictable than they were. Daniel Kahneman describes it at length in his work on judgment, and the effect is brutal for founders: you cannot learn from decisions you have unconsciously rewritten.

A decision log freezes your reasoning in time. Six months later you open the entry and read exactly what you believed, expected, and how confident you were. The result is no longer the only data point. You can ask the better question: given what I knew then, was that good reasoning or lucky reasoning? Those are very different, and only the log lets you tell them apart.

Why solo founders need a decision log more than teams do

A team is a distributed memory. People disagree in meetings, someone writes a doc, and a year later three people can reconstruct why the architecture went one way. The friction of a team accidentally produces an audit trail.

A solo founder has none of that. The decision happens in your head, gets executed, and the reasoning evaporates. When you revisit it later, you have the outcome and a vague feeling, but not the actual logic. That gap is where founders repeat the same mistake in a new costume, because they never captured the pattern the first time.

The log replaces the team’s accidental memory with a deliberate one. It also does something subtler: writing the decision down forces you to actually have reasons. A surprising number of choices that feel obvious in your head turn out to be one unexamined assumption when you try to write the second sentence. The act of logging is itself a quality gate, before you have even reviewed anything.

What to capture in every entry

An entry that is missing the right fields is a diary, not a tool. Here is what each one is for, and why the two everyone skips are the two that matter most.

Date. Obvious, but it anchors the entry in your situation at that moment, which is half the point. The same decision is good or bad depending on your runway, your stage, and what you knew.

The decision. One sentence. “Switch the API from REST to a typed RPC layer.” If you cannot state it in a sentence, you are logging two decisions and should split them.

Context. What forced this call now. The constraints, the deadline, the pressure, the thing that made doing nothing not an option. Future-you will not remember the context, and the context is what makes the reasoning legible.

Options considered. The real alternatives, including “do nothing.” This is the field that catches you. If you only wrote down one option, you did not decide, you reacted.

Reasoning. Why this option over the others. The actual logic, not a justification. Write it the way you would explain it to a skeptical co-founder.

Expected outcome. What you think will happen, concretely enough to be checked later. “I expect signups to convert 10 to 20 percent better” beats “I think this will help.” Vague predictions cannot be graded.

Confidence. A number, even a rough one. “70 percent this is right.” This is the field almost everyone skips, and the single most valuable one, because it is what lets you calibrate. A founder who is 90 percent confident and right half the time is overconfident, and will only ever see that pattern if they wrote the confidence down.

Review date. When you will actually know. Set it by the decision’s natural feedback loop, not a default cadence. A pricing change might be reviewable in 60 days; a hiring call in six months.

The Founder Decision Log: a copy-pasteable template

This is the framework I use. It is deliberately boring, because boring survives. Copy this block into a text file, append a new one each time, and never reformat it.

## [YYYY-MM-DD] Decision: <one sentence>

- Context:        Why this call, why now. The constraint forcing it.
- Options:        1) ...  2) ...  3) do nothing
- Chosen:         Which option, stated plainly.
- Reasoning:      Why this over the others. The real logic.
- Expected:       What I think happens, concrete enough to check.
- Confidence:     <0-100%>  (be honest, not aspirational)
- Reversibility:  two-way door (reversible) | one-way door (irreversible)
- Review date:    YYYY-MM-DD  (when I will actually know)

--- review (filled in later) ---
- What happened:  <outcome, written at review time>
- Reasoning vs reality:  was the call good, or just lucky / unlucky?
- Lesson:         one line I want to carry forward

The structure does three jobs. The top half captures the decision before the outcome. The Reversibility field forces the one-way / two-way classification (next section). The bottom half stays empty until the review date, the part that turns a pile of notes into a calibration system.

A table view of the same fields, if you prefer it for scanning:

Field	What goes here	Why it matters
Date	When you decided	Anchors the decision to your stage and runway
Decision	One sentence	Forces a single, clear call
Context	The forcing constraint	Makes the reasoning legible later
Options	Real alternatives + do nothing	Proves you decided, did not react
Reasoning	Why this option	The thing you will grade later
Expected	Concrete prediction	Lets you check the call against reality
Confidence	A 0 to 100% number	The field that calibrates judgment
Reversibility	One-way or two-way door	Sets how much deliberation it deserves
Review date	When you will know	Triggers the review that closes the loop

Reversible vs irreversible: the one-way and two-way doors

The most useful classifier I have found for founder decisions comes from Jeff Bezos, who laid it out across Amazon’s shareholder letters. He splits decisions into two-way doors and one-way doors, and the distinction changes how much time a decision deserves.

A two-way door is reversible. You walk through, and if you dislike what is on the other side, you walk back out at low cost. Most product, copy, pricing-experiment, and tooling decisions are two-way doors. The right move is to decide fast, because the cost of being wrong is small and the cost of deliberating is real. Bezos’s argument is that as organizations grow they start treating two-way doors like one-way doors, which produces slowness and timidity. Solo founders do the same thing, just in their own heads.

A one-way door is hard or expensive to reverse. Picking a co-founder, taking on debt, a database migration with no rollback, a public pricing commitment you cannot quietly walk back, the legal and banking rails your money flows through. These deserve slow, careful deliberation, because the cost of being wrong is high and you do not get a cheap second try.

Putting Reversibility in the entry forces the question at decision time: is this actually a one-way door, or am I agonizing over something I could undo in an afternoon? The honest answer is “two-way door” far more often than it feels like in the moment, and naming it is permission to move faster on the calls that do not deserve a week of worry.

How to review the log and calibrate your judgment

A decision log that you write and never reopen is just a more disciplined diary. The entire payoff is in the review, and the review is where most people quit, so make it dead simple.

Once a month, open the log and read every entry whose review date has passed. For each, fill in the bottom half: what happened, and then the question that matters, was the reasoning good or the outcome just lucky? A decision can be well-reasoned and turn out badly (a smart bet that lost), or badly-reasoned and turn out fine (you got away with it). Scoring the reasoning, not the result, is the whole skill. Annie Duke makes this case in Thinking in Bets: in any domain with luck in it, you have to separate decision quality from outcome quality, or you will learn exactly the wrong lessons.

The confidence field is what turns this into calibration. Over a year of entries you will see your own pattern. Maybe you are reliably overconfident on technical decisions and underconfident on customer-facing ones. Maybe your 50 percent calls come true 50 percent of the time, which means you are well calibrated and should trust your gut more. You cannot see any of this without the numbers written before the outcome.

Farnam Street’s decision journal framing is the cleanest public version of this loop, and it is worth reading alongside this post. The mechanism is the same: record the reasoning, set a review, and grade your past self honestly. Do that for a year and your judgment stops being a vibe and starts being something you have actual evidence about.

Keep it lightweight, in plain text

The fastest way to kill this habit is to make it a project. I have watched founders set up a Notion database with relations and rollups and tags, use it for a week, then abandon it because opening the right view became a small chore. The friction compounds against you every single day.

I keep mine the way I keep everything else: a plain Markdown file in my working directory, edited in Neovim, appended to from the terminal I already have open. No app to launch, no sync to wait on, no schema to maintain. A new decision is a few lines at the bottom of a file. The lack of ceremony is a feature, because the only version of this that helps you is the one you keep doing.

If plain text feels too primitive, the bar to clear is simple: whatever you use has to be openable and appendable in under five seconds, or it will lose to the rest of your day. A file in your code repo passes that bar. Most tools with a loading spinner do not. The log’s value comes entirely from accumulated entries over months, and you only accumulate them if writing one is effortless.

What I would do differently

The honest failure mode of decision logs is not too little structure, it is too much. The first time I tried this I over-designed the template, added clever fields, and made each entry a ten-minute writing exercise. It died in about two weeks, exactly when it had no entries old enough to review yet, so it never paid me back once. The template should be slightly too simple, not slightly too rich, because a log you keep beats a perfect one you abandon.

The other thing I would change is logging smaller decisions than feel worth it. The instinct is to only log the big one-way-door calls, but those are rare, so you build no habit between them. Logging some two-way-door decisions too, even ones you are fairly sure about, keeps the muscle warm and catches the overconfident calls you would never have flagged as risky. The decisions that teach you the most are often the ones you were sure about and wrong on, and you only catch those by logging the confident calls, not just the hard ones.

If you take one thing from this: start the file today, keep the template boring, write the confidence number even when it feels silly, and put a real review date on every entry. The compounding is the point.

What is a decision log, in one line?

A decision log is a dated record of your meaningful choices, written before the outcome is known, capturing your reasoning, expectations, and confidence so you can later grade your judgment honestly. It is the founder’s antidote to hindsight bias, and for a solo operator it replaces the institutional memory a team would otherwise provide.

The one-line definition matters because people confuse it with a journal or a to-do list. It is neither. A to-do list is about what to do next. A journal is about what already happened. A decision log sits in the narrow gap between: the moment after you decide and before you act, when your reasoning is still uncontaminated by the result. That moment is the only one worth capturing, and it is gone within hours if you do not write it down.

What should you write in a decision log?

Write the date, the decision in one sentence, the context that forced it, the options you considered, your reasoning, your expected outcome, your confidence as a number, and a review date. Then leave a blank section for the outcome, which you fill in only at review time. Eight fields up front, one section later.

Of those, the two founders skip and then regret skipping are confidence and expected outcome. They feel optional in the moment because the decision seems obvious. They are exactly the fields that make the log a calibration instrument instead of an archive. Without a recorded confidence level you can never discover that you are systematically overconfident, and without a concrete expected outcome you have nothing specific to check reality against. Write both, even when they feel unnecessary, because the entry that feels too obvious to log is usually the one hiding an untested assumption.

Want the system, not just the article?

The Bootstrapped Founder Operating System ships with the Founder Decision Log as a ready-to-use template plus a monthly review checklist and a calibration tracker, so you can score your own judgment over time instead of guessing. It is the same plain-file system I run, packaged so you can start today. Launch price: $29.

Get the workbook →