Not a crash. A kernel panic. The kind where the operating system itself gives up, prints a wall of output no human should have to read, and reboots. I stared at the restart screen and felt that specific kind of alone that only solo technical founders know.
No incident channel. No on-call rotation. No one to call. Just me and whatever I had broken.
My first instinct was to open the logs and figure out what failed. That was the wrong instinct. It took me an hour of log-diving before I figured out that the question was not "what failed." The question was "what combination caused it."
I had been running three heavy processes at the same time. A large model download pulling gigabytes from a remote server. A local AI inference process that was consuming all available RAM. A full test sweep across the codebase. Each one of those, individually, was completely fine. Together, they were asking the machine to hold three competing resource spikes at once. The operating system had no choice but to shut everything down.
What I had been doing was treating my local machine like it had infinite capacity. That assumption is invisible when things are working. It only appears when everything fails at once.
A postmortem is a document you write after something breaks. At a large company there is usually a team, an incident commander, a structured timeline. The process exists partly to learn and partly to distribute accountability.
Solo founders skip this. I skipped it for years. There is no audience, no accountability partner, no one waiting on the document. Something breaks, you fix it, you move on. The lesson stays in your head for a few weeks. Then it fades.
The kernel panic changed that for me. Partly because it was embarrassing enough that I actually wanted to understand it properly. Partly because I had finally built a system complex enough that I could not hold all its failure modes in my head at once.
So I wrote the postmortem. Just for me. Three sections: what happened, what actually caused it, what I am changing.
Writing "what happened" is easy. You already know the story. You were there.
Writing "what actually caused it" is where the postmortem earns its keep.
Because what actually caused my kernel panic was not the model download, or the inference process, or the test sweep. What caused it was my failure to recognize that those three things belong to completely different categories of work, with completely different resource profiles.
The download is network and disk bound. The local inference process is CPU and RAM bound. The test sweep pulls on all three simultaneously. Running them in sequence is fine. Running them at the same time is a bet that the machine can absorb all three at once. That bet loses on a Tuesday morning when you are feeling productive and not paying attention, and it will lose again the next time you forget about it.
Once I wrote that down, the fix was obvious. Two classes of work. Local-heavy tasks run one at a time, in sequence. Remote work runs in parallel, with a hard cap on concurrent threads. Before any heavy task, I check machine load and available disk space. If either is above a threshold, the heavy task waits.
That is the entire discipline. It fits in four sentences.
Writing "what I am changing" is where most solo founders stop, because the lesson feels obvious in retrospect. Of course you should not run three heavy things simultaneously. Of course you should check system load first. The insight seems too small to be worth writing down.
But that is the thing about postmortems: the lesson is almost always obvious in retrospect. The point is not the lesson. The point is that you now have a document you will actually re-read at 2am six months from now, when you are about to do the exact same thing again.
Lessons that stay in your head fade. Lessons you write down stay written down.
I have re-read that postmortem twice since I wrote it. Once when I was about to kick off a heavy rebuild while an inference process was still warm in memory. Once when I needed to explain to a collaborator why the concurrency rule existed and I wanted to give them the real answer, not an approximation of it. Both times, the document did work I would have otherwise done from scratch, from memory, probably less accurately.
There is a version of this that sounds like engineering hygiene advice: track your incidents, write your runbooks, build your disciplines. That is all true, and also kind of beside the point.
The real reason solo founders should write postmortems is that you are the only keeper of your system's history. There is no institutional memory. No long-timer who remembers why the rule exists. No thread from three years ago explaining the decision. Just you and whatever you wrote down.
When you skip the postmortem, you are not just losing a document. You are losing the only record that the failure happened at all, and the only evidence that you thought carefully about what to do differently.
Six months later, when the same combination of conditions reappears, you will repeat the mistake unless you wrote yourself a letter.
Write the letter.