How to know when to kill a side project (and how to do it cleanly)
Kill a side project when the evidence, not the mood, says so: no paying customers after a full validation cycle, flat or falling usage across three months, a market that keeps saying the problem is not urgent, or a founder who has stopped opening it. A bad week is not a signal; three flat months with active effort is. The real cost of a zombie project is not money — it is the attention and the nine lives it consumes while you avoid deciding.
The workflow
Feeling discouraged after a quiet week is not evidence. Three months of flat usage while you were actively working on it is. Write down what has actually happened — customers, revenue, weekly active users, month by month — before you allow yourself an opinion. Most kill decisions are made and unmade repeatedly because founders keep relitigating with feelings rather than a table.
Many projects that feel dead were never validated in the first place: they were built, launched quietly and left to be discovered. If you never asked anyone to pay, never sent forty messages and never ran a test with a threshold, the honest verdict is unknown rather than dead. That is a different decision — one week of real distribution effort answers it.
- Input
- 14 months old, 40 free users, 0 paid, no marketing since launch, founder opens it monthly
- What comes back
- UNTESTED, not dead. Zero paid with zero distribution effort means you have never run the experiment. Give it one focused week — 40 outreach messages and a paid tier — and then decide. If that week produces nothing, the answer is clean.
Run it yourself — free, no signup:
1.Has anyone paid you actual money for this?
2.When you stop pushing for a week, what happens?
3.Of the people who tried it, how many still use it a month later?
4.Do you have one channel that reliably brings strangers?
5.Honestly — do you still want to work on this?
6.In the last month, did you learn something that changed the plan?
Answer all six for a verdict. None of them ask what you've already spent — that's the point.
Subscriptions, domain, hosting, the support you still answer, and the attention it takes from the next thing. The last one dominates: a project you think about weekly but do not work on consumes the mental space a new idea needs. Write the monthly dollars and the honest weekly hours, and the decision usually stops being close.
Almost every dead project leaves something valuable: an audience list, a piece of infrastructure, a domain, a reusable component, or a specific skill. Identify it before shutting down, because founders who close in a hurry throw away the mailing list that would have launched the next thing to a warm audience.
Tell users with notice, export their data, refund anything prepaid, and cancel the subscriptions the same day. If people paid you, over-communicate. A clean shutdown protects a reputation that outlives the project by years — and a founder who killed something honestly is far more trusted than one whose product simply stopped responding.
Five hundred words: what you assumed, what actually happened, what you would test first next time. Written at the moment of the kill it is honest; written six months later it becomes a story where you were unlucky. This document is the compounding asset of a founder who kills things well, and it is why the second attempt takes half the time.
Questions founders ask about this
- What are the signs a side project should be killed?
- No paying customers after a full validation cycle, flat or declining usage across three active months, buyers who consistently say the problem is not urgent, and a founder who has stopped opening it. One bad month is not on that list.
- How long should I give a side project before quitting?
- Judge by effort, not by calendar time. Three months of real, active work with distribution attempts is a fair test; three years of neglect is not evidence of anything except neglect.
- Is it quitting too early if I stop after a few months?
- Not if you ran the test. The failure mode to avoid is stopping without ever having asked anyone to pay — that is abandoning an experiment you never started rather than acting on a result.
- What should I do with users when I shut down?
- Give notice, export their data, refund anything prepaid, and say plainly why. A clean shutdown costs a week and protects a reputation that will outlast the project by years.
- Should I sell a failed side project instead of killing it?
- Worth trying if it has users, revenue or a decent domain — small marketplaces exist for exactly this. Set a short window for a sale so the attempt does not become another way to avoid deciding.
Next, founders usually do this
- How to write kill criteria before you fall in love with the idea6 steps
- How to calculate runway for a bootstrapped SaaS (and what to do with the number)6 steps
- How to choose between two startup ideas without a spreadsheet fantasy6 steps
- What to do when everyone says they love your idea and nobody buys6 steps
The tools used above have their own pages — Kill-or-Continue Quiz — and the SOP SOP: Kill a failing venture without sunk-cost bias runs the same ground in more depth. Also worth reading: the Nine Lives Doctrine, and real verdicts from ideas kitty has run this workflow on.
kitty.build runs this entire workflow for you
Every step above — the research, the competitor read, the numbers, the honest verdict — is what nine specialist AI boards do automatically when you feed her an idea. She will tell you to kill it if it deserves killing. First idea is free.
Feed her an idea — freeNo card · Failed tasks are free · Your repo, your domain, your revenue