The fans had been spinning at a pitch I only hear during video rendering. The cursor was moving in that slow, sticky way it moves when the OS is losing the argument with RAM. And I had that particular feeling, the one that comes right before you realize you cannot stop what is about to happen.
Then the kernel panic. Black screen. The kind of crash that does not give you a stack trace or an error log. It just stops.
This was a morning in May. I had been building hard. A local AI inference model was loading into memory, a big one, the kind that takes minutes and several gigabytes before it is ready to take a single query. At the same time, I had dispatched a parallel fleet of cloud API calls to run a review sweep across several documents. Alongside that, a full automated test suite was running across the codebase I had just modified. And layered underneath all of it, an orchestration system was doing its own background processing, checking on jobs, routing work, keeping state.
Each task, in isolation, was reasonable. Each one would have finished without incident if it had been the only thing running. I had done every one of them before. But I had never done them simultaneously, and on that morning I learned exactly why that was a bad idea.
The Mistake That Looks Reasonable Until It Isn't
The mental model most of us carry about resource contention goes something like this: if one task claims half the memory and another claims half, the math should work out. A little tight, but fine.
That model is wrong the moment you mix certain categories of work.
The crash forced me to sit with a question I had been avoiding: what, exactly, is the fundamental difference between the kinds of work I am doing? Not by domain or purpose, but by the kind of load they impose on the machine.
I spent the day after the crash reconstructing what had actually happened. The local model load was RAM-intensive and held the resources it claimed for an extended period. The cloud API fleet was network-bound and spawned process threads that competed for CPU scheduling. The test sweep was both I/O-intensive and CPU-intensive, constantly reading files and computing results. The orchestration daemon needed consistent access to disk and memory for its state.
None of these played well together. But more importantly, I had mixed two categories of work that should never share a time window: local-heavy tasks that demand a machine almost entirely to themselves, and distributed tasks that can run in bounded parallel because their weight falls on remote infrastructure.
The kernel panic was not a bug. It was the machine telling me I had misunderstood my own workload.
The Protocol That Came Out of the Wreckage
A crash of that kind tends to produce either frustration or clarity. I have learned to aim for clarity.
The clarification I wrote for myself that afternoon was about resource classes. Some tasks are local-heavy. They need to run alone, serially, with the machine's full attention, because they compete with everything else for RAM, CPU, and disk. Loading a large inference model. Running a full test sweep. Triggering a heavy orchestration job outside its scheduled window. These things are incompatible with each other and with anything else that demands significant resources at the same time.
Other tasks are what I started calling remote-fleet work. They dispatch to external APIs and wait for responses. The actual computation happens elsewhere. These can run in bounded parallel, not unlimited, but several at once, because the local machine is mostly waiting, not working.
The rule I came up with was simple: never cross the classes. If a local-heavy task is active, no fleet work starts. If fleet work is active, no local-heavy task starts. And before any heavy task begins, I now check three things: CPU load over the last minute, available disk space, and whether any other heavy task is in flight.
That last check sounds obvious in retrospect. It was not obvious when I was in the middle of building something at speed and just needed all the things to run.
What Solo Founders Carry That Teams Do Not Have To
There is something specific about building complex systems alone that creates this kind of risk.
In a team, the person loading the inference model is probably not also running the test suite. Resource contention at the infrastructure level gets distributed across people without anyone designing it that way. You share machines, or you have separate machines, or the pipeline forces serialization as a side effect of handoffs between people.
Solo, you are the pipeline. Every task is yours to schedule, and the temptation, especially when you are in a state of flow, when the work is moving fast and everything feels connected, is to run everything together because everything feels connected.
The discipline that fixed this for me was a forcing function: written resource classes. A short document that puts each category of heavy work in exactly one bucket, with a hard rule about cross-mixing. Once it was written down, it became visible. And once it was visible, I stopped doing the thing that crashed my machine.
I still run into the temptation. The model is loading and I think, I will just kick off this API sweep while I wait. That thought is the red flag now. That is exactly the configuration that produced the 10:58 crash.
The Thing About Postmortems Is That They Compound
Solo founders often skip the postmortem. There is no one to write it for, and the format feels designed for teams. Who are you presenting to? Who needs to understand the incident? You already know what happened.
That instinct is wrong, and I say that as someone who learned it the hard way.
The value of a postmortem when you are building alone is not the audience. It is the forcing function of articulation. Writing down what happened, at the level of root cause rather than symptom, is a different cognitive act than just knowing what happened. The kernel panic gave me a clear memory of the chaos. The postmortem I wrote the next day gave me a transferable principle.
Local-heavy and remote-fleet work do not mix. A preflight check before any heavy task is non-negotiable. And the temptation to cross classes is highest exactly when the work is going well and the momentum feels unstoppable.
Write the postmortem. Write it for yourself. Write it while it still stings, because that is when the root cause thinking is sharpest. File it somewhere you will see it. And then when the same temptation appears three months later, you will have something to read instead of something to repeat.
The machine will tell you. You just want to hear it in a document first.