How to Kill a Side Project Without Guilt

Almost none of my dead projects were killed. They stopped. There was no decision, no date, no reason. One week I was working on it and the next week I was not.

Abandoned and killed are not the same thing

An abandoned project stays open in your head. It is still technically alive, still something you might come back to, still taking up the small amount of attention that unresolved things take.

A killed project is closed. You decided, you wrote down why, and it is over. The relief is real and most people have never felt it, because they have never actually killed anything.

The one line that does the work

Require yourself to write one line: why did this die? Not a post mortem, one line. Lost interest after the auth flow. The idea only worked if I had users I do not have. I wanted to learn the framework, and I did, and the app was never the point.

Two things happen. First, writing it is uncomfortable enough that you sometimes finish the project instead, which is a feature. Second, after ten of them you can read your own list and see the pattern. Mine is obvious in hindsight: I kept starting projects whose value depended on an audience I had not built.

Sunk cost is not a reason to continue

The weekends you already spent are gone whether you continue or not. That is the sunk cost fallacy, and side projects are where it does the most damage, because nobody else is around to point it out.

The question is never whether the past effort was worth it. It is whether the next ten hours are better spent here or somewhere else.

Make killing a first class action

In One Project OS a project leaves the active slot in exactly two ways: shipped, or killed with a written reason. Killed projects go to a graveyard page with their reasons listed, which is the most useful screen in the app. It is also why allowing one active project at a time works: the queue stays locked until you make the call.