When to Kill Your Side Project (And How to Do It Cleanly)
80%+ of side projects aren't profitable within 12 months. Here are the kill criteria to write before you build, and the 90-minute shutdown checklist when it's time.
The Project You Should Have Killed in March
It's not dead. That's the problem. It gets a commit every few weeks, a small hosting bill every month, and a corner of your attention every single day.
Nobody writes about this because there's no story in it. Projects rarely die in a dramatic moment — they fade, in a drip of unread analytics emails and auto-renewing domains.
The numbers are not ambiguous. Over 80% of side projects aren't profitable within 12 months (Indie Hackers survey), and 67% of side-project developers cite lack of time as the reason they stopped (ACM research, via Bright Curios). Pieter Levels shipped 70+ projects and 4 grew — roughly a 95% failure rate from someone unusually good at this (FoundStep).
Here's the number that should actually bother you: 35% of indie product failures involve more than six months spent on a dead MVP (WhatToBuild, citing a 2024 Indie Hackers analysis). That's not six months of learning. It's six months of refusing to learn.
Killing well is a skill. It's also the only way to have enough attempts for one to work — the arithmetic behind the $1K/month idea.
Need the next attempt ready before you shut this one down? Keep a queue at startup ideas.
Write the Kill Criteria Before You Build
The core insight from project risk management, translated for solo founders: kill criteria are the lines you decide in advance you won't cross, and they trigger a mandatory review, not an automatic execution (Carl Pritchard).
Written before you start, they're a neutral instrument. Written after you're 400 hours in, they're a negotiation you will lose against yourself.
A defensible default set for an indie MVP:
| Criterion | Trigger |
|---|---|
| Kill date | 90 days from launch, on the calendar, written down |
| Signal floor | Zero unsolicited user contact in 30 days |
| Traction floor | Fewer than 100 signups in 30 days, or under 10% week-over-week retention at 60 days |
| Payment gate | Zero paying customers at day 90 (if that was the goal) |
| Effort gate | Four weeks with no real commit |
| Energy gate | A full month of dread when you open the repo |
Ninety days is the number worth defending: long enough to build something real, short enough that the date stays believable. Projects without a time boundary expand indefinitely — scope grows, motivation drops, and the project joins the pile.
The four-week commit gap is the sneakiest one. Past that point, the cost of reloading the project into your head grows faster than your motivation to do it. The project is already over; you just haven't filed the paperwork.
Set these up so the data surfaces without you looking for it. A one-line weekly email from your own analytics, or a Google Sheet you update Fridays. The point is removing emotion from the moment of decision — instrument it once, using the five events from what to measure after you ship.
The Faster Version: 30-Day Bets
If you ship fast, tighten the loop hard. One portfolio operator running ~14 MVPs gives each 30 days to produce one real signal — not product-market fit, not revenue, just evidence that somebody out there cares (Indie Hackers).
Signals that count:
- Organic traction without paid push. If search sends nobody after the indexing window, either the topic has no demand or your angle is wrong.
- A second visit. Someone came back without a nudge.
- Unsolicited feedback. The rarest and strongest. One email that says "I tried this and…" changes everything. No email in 30 days is also a message.
Two honest caveats, because this framework gets misapplied constantly:
- It only works as a portfolio. With one product, killing at 30 days is just quitting. With ten bets, killing is how you find the one.
- It requires shipping in a week or two. If your MVP takes three months to build, a 30-day test window is incoherent. The 3-screen MVP is what makes short windows possible.
Kill vs. Pivot vs. Park
When criteria trigger, you have three legitimate outcomes. Choose explicitly.
Kill. No signal at all, and no hypothesis left you haven't tested. Shut it down.
Pivot — but only if you can write down what specific evidence justifies it and what new kill criteria apply. "The audience was wrong, and three of them asked for X instead" is a pivot. "Maybe if I added a dashboard" is a sunk-cost costume.
Park. Traffic exists and you don't. Freeze features, keep the lights on, set a calendar reminder for six months out. Legitimate — as long as "parked" is a decision, not a description of the last year.
The rule that keeps you honest: money and time already spent are gone. The only valid question is what the next 90 days of your attention are worth against the next best use of them.
Sahil Lavingia is often cited here for shutting down a game he'd sunk roughly $100K into, and redirecting that attention toward what became Gumroad. The lesson isn't discipline for its own sake. Attention — not money, not code, not ideas — is the scarcest thing you have, and it's the only input that determines what survives next.
Killing is easier when the replacement is already picked. Line up the next one from startup ideas before the review date arrives.
The Clean Shutdown Checklist (90 Minutes)
Killing badly hurts your reputation. Killing cleanly costs you an evening and builds it.
- Email your users first. Even if there are seven. State the shutdown date, that their data is exportable until then, and thank them plainly. No corporate voice, no "difficult decision" boilerplate.
- Ship a data export. One CSV endpoint or a manual export you email. This is the single thing users remember.
- Refund or cancel gracefully. Cancel subscriptions immediately; refund the current period. Cheap goodwill; expensive to skip.
- Set a real end date and honour it. Two to four weeks out.
- Cancel the infrastructure. Hosting, monitoring, email provider, third-party APIs. Check your card statement a month later for the one you forgot.
- Keep the domain. Domains are cheap and killed products do occasionally come back with a different angle. Point it at a one-paragraph page explaining what happened.
- Salvage the code. Auth flows, billing plumbing, component libraries, database schemas — pull the reusable parts into a starter template. This is how each attempt gets faster than the last.
- Write the postmortem. One page: what you believed, what you shipped, what actually happened, what you'd test first next time. Publish it if you want distribution — shutdown posts perform embarrassingly well, and they age into credibility.
- Write the re-entry condition. One sentence: "I'd revisit this if [specific thing] happened." It stops the project from renegotiating its way back into your week.
Signs You're Rationalising, Not Deciding
- You've moved the launch date more than twice
- You're building features nobody asked for because building feels better than selling
- You describe traction in relative terms only ("up 40%" from four visits)
- Every conversation ends with "just one more thing and then I'll push it"
- You've started calling it "a learning experience" while still spending Saturdays on it
- You can't remember the last time a stranger used it
Any three of those and your criteria already triggered. You just haven't looked.
FAQ
Isn't killing things quickly just giving up?
Only if you have one bet. The failure data is consistent across everyone who publishes it — most projects don't work. Fast kills are how you afford enough attempts to find the exception.
What if it starts working right after I kill it?
Rare, and you kept the domain and the code, so re-entry is cheap. The far more common failure is the opposite: a year spent on something that was already answered in month two.
How do I tell "no traction yet" from "no traction ever"?
Distinguish leading from lagging. Zero organic search, zero return visits, and zero unsolicited contact after 30 days is a leading signal — it doesn't improve on its own. Slow revenue with returning users and inbound questions is a lagging signal, and worth patience.
Should I tell people I killed it?
Yes. Publicly, briefly, without drama. It closes the loop, it's genuinely useful to other builders, and it makes your next launch land with people who trust you.
TL;DR
Over 80% of side projects aren't profitable within 12 months, and 35% of indie failures involve six-plus months on an MVP that was already dead. The fix isn't working harder — it's writing kill criteria before you build.
Defaults worth using: a 90-day kill date, zero unsolicited contact in 30 days, under 100 signups in 30 days, a four-week commit gap, and a month of dread. Trigger a mandatory review, then choose kill, pivot (only with written evidence and new criteria), or park (as a decision, not a drift).
Shut down cleanly: email users, ship a data export, refund, cancel infrastructure, keep the domain, salvage the reusable code, and publish a one-page postmortem with a written re-entry condition.
Then spend the attention you just freed up on the next bet: startup ideas.