Killing a Project on Purpose: Pre-Commitment Rules for Solo Builders
Most solo builders are good at starting things and bad at stopping them. A project quietly drifts from an experiment into an obligation, and by the time anyone asks whether it is still worth doing, the answer has been buried under months of effort. The fix is not more willpower. It is writing down, before the work begins, the conditions under which you will stop. This article walks through how to build those conditions, how to test them, and what to ask yourself when a stop signal appears. Nothing here is financial, legal, or medical advice; it is a general method for thinking clearly about your own work.
Why sunk cost beats judgment without a rule
Sunk cost is the feeling that hours already spent should count toward the decision to continue. They should not, but the feeling is strong because the hours are vivid and the future is abstract. A builder who has spent three months on a tool will often justify a fourth month by pointing backward at the first three rather than forward at what the fourth month will actually produce.
A pre-commitment rule works because it moves the decision to a moment when you are not emotionally invested. When you write the criteria on day one, you are essentially negotiating with a version of yourself who has not yet fallen in love with the idea. That version is usually more honest.
Writing kill criteria before the first build step
Start with three to five conditions that would tell you the project is not working. Make them observable. 'The idea feels stale' is a feeling, not a condition. 'Fewer than a set number of people complete the first test task by a set date' is a condition you can check. 'Weekly hours exceed a limit I set for this project for four consecutive weeks' is another.
Include at least one condition about learning, not only outcomes. A project can fail its target and still teach you something worth keeping. Write down what you expect to learn and what result would tell you the learning is exhausted. When you reach that point, stopping is a graduation, not a defeat.
Assign a review date. Without a date, kill criteria become suggestions that get postponed indefinitely. Put the review on a calendar and treat it like an appointment you cannot reschedule without writing down why.
A checklist for the review meeting with yourself
When the review date arrives, work through these questions in order and write the answers down rather than holding them in your head.
First, which kill criteria were met? Name them exactly. If none were met, say so plainly and note whether the criteria were set too loosely to be useful.
Second, what changed since the project started? Distinguish between changes in the market or your situation, changes in your own interest, and changes in the evidence. Only the second and third should weigh heavily.
Third, what is the smallest next test that could change your mind? If you cannot name one, that is usually a sign the project has stopped generating new information.
Fourth, what would you tell a friend who described this exact project and this exact evidence? People are often more accurate when advising others than when judging themselves.
Fifth, what is the cost of continuing for another period, measured in hours, attention, and the opportunities you give up? Be concrete. 'Some time' is not a number.
Stopping cleanly so the lesson survives
A stopped project should end with a short written record: what you tried, what the criteria were, which ones were met, what you learned, and what you would do differently. Keep this record where you will find it again. The most common mistake after stopping is to quietly move on without extracting anything, which means the next project repeats the same blind spot.
Consider sharing a brief version publicly if that fits your practice. Builders who document stops alongside launches help readers understand that iteration includes closing doors. Be careful not to overstate results you did not measure.
Finally, protect the decision from reversal. If you find yourself wanting to revive a stopped project within a few weeks, return to the written record and ask whether new evidence has appeared or whether you are simply missing the feeling of starting. Only the first justifies reopening the work.
Using the method across your portfolio
Once the habit exists for one project, apply it to everything you are running. Keep a simple list with each active project, its kill criteria, its next review date, and its current status. When you review the whole list, you may find that three projects are competing for the same hours and only one has real evidence behind it.
The goal is not to kill more projects. It is to make each continuation a deliberate choice. A builder who stops two projects on schedule and doubles down on a third with clear signals is doing better work than one who keeps everything alive out of hope. Clear rules make that difference visible.