The Side-Project Kill List: 6 Signals to Quit and How to Kill Gracefully

An indie developer's most expensive resource isn't servers or API bills — it's time. And time's biggest black hole isn't "lack of ideas." It's "refusing to kill projects" — that thing you built eight months ago, still maintain weekly, and know in your heart will never take off. Pieter Levels shipped 12 products in a row, killed 11, kept only Nomad List. His summary: "My secret wasn't building 12 products. It was killing 11."

This article gives you a kill list: 6 signals it's time to quit, how to kill a project gracefully, and what the time you save is actually worth.

How common is this? Of the 20+ indie developers I've interviewed, more than half were simultaneously maintaining 2+ "zombie projects" — users but no growth, revenue but not a living, too tasteless to keep, too wasteful to drop. And looking back, nearly everyone's signature work was born in the year after they "killed the old thing and went all-in on the new direction." Killing a project isn't a loser's exit — it's a winner's repositioning. What you lack was never the perseverance to "hang in there" — it's a mechanism for cutting losses in time.

6 Signals It's Time to Quit

One signal alone doesn't mean kill. But 3+ at once is a red light.

Signal 1: three straight months of zero growth in the core metric. Core metric, not busyness. You're fixing bugs and answering user emails every week — looks busy — but signups, paying users, and revenue are all flat. Busyness is the best anesthetic: it feels like progress while you're maintaining a stationary object. Give every project one north-star metric; three months without movement puts it on the watch list.

A common self-deception here: mistaking vanity-metric growth for comfort. Twitter followers up 200, GitHub stars up 50 — but signup conversion is still zero. One iron rule: growth that can't lead to revenue is hallucination. Keep three numbers on the dashboard: new paying users, MRR, retention. Everything else is noise.

Signal 2: you're maintaining it on willpower. Ask honestly: opening this repo — excitement or a sigh? If you've needed a pep talk before every session for a month straight, the project is already dead; you just haven't signed the papers. An indie developer's energy is single-threaded — a project sustained by willpower is stealing the passion you could go all-in with on the next opportunity.

Distinguish normal burnout from a dead project. Normal burnout is cyclical — three months of grind, one week of rest, and you want to build again. A dead project is directional — you come back from rest and still don't want to touch it; user emails even annoy you a little. The test: take 7 days fully off, don't think about the project, and watch your first reaction on day one back — "kind of want to get back to it" versus "ugh, this again." The latter is signal 2.

Signal 3: user feedback is forever "minor tweaks," never an "aha moment." Healthy early projects get users saying "this feature saved me"; dying ones get "can this button be another color?" When you haven't heard a single eye-lighting piece of feedback in three months, the product isn't hitting a real need — it's serving "politeness users."

What's a "politeness user"? Someone who says "looks great, keep it up!" but never pays and never refers a friend. Indies get misled by this feedback most because it sounds positive. The filter: watch whether users will "pay a price" — paying, filling out a tedious onboarding form, migrating their data. Users who only move their mouths get their feedback weighted at 30%. If 90% of your user list is that type, no real need supports the product.

Signal 4: you're afraid to look at the data. When did you last open the analytics dashboard? If the answer is "weeks ago" and it's deliberate — because looking hurts — the data has already told you the answer. Avoiding data is a founder's most honest body language.

Pair this signal with a forcing mechanism: every Monday 9 AM, a calendar reminder — "look at data, 15 minutes," non-negotiable. Three numbers: new users, paid conversion, churn. Four straight weeks of not daring to click that reminder — or clicking and closing it in three seconds — stop lying to yourself. You're using "not looking" to protect the fantasy that "it's still salvageable." Data doesn't improve because you ignore it; it only makes you miss the stop-loss window.

Signal 5: all growth is hand-pushed by you. Every tweet brings 10 signups; silence means zero. Every customer came from a conversation you started; the product acquires no one by itself. That means there's no product-market fit — only founder-market fit. You personally are the only growth channel. That's normal very early, but six months in it means the product has no virality and no retention of its own.

Run the "vacation test": if you disappeared completely for two weeks — no shipping, no tweets, no email replies — what happens to the numbers? A healthy product decays slowly; a dying one flatlines. It's brutal, but it measures whether the project has a life of its own, not whether you do.

Signal 6: the opportunity cost is too big to ignore. Do the math: 15 hours a week on this project is 780 hours a year — 4.5 months of full-time work. Meanwhile your backlog holds two ideas you're more excited about. Killing isn't admitting failure — it's buying back 780 hours to invest where expected value is higher.

Opportunity cost has an invisible version too: mental bandwidth. A half-dead project, even at 2 maintenance hours a week, runs a background process in your head — its bugs in the shower, its user complaints before sleep. That low-power anxiety costs more than the actual hours. Killing it shuts down not just a repo but a process that's been eating your memory for years. That lightness is something only people who've killed projects understand.

How to Kill a Project Gracefully

Killing isn't "shutting down the server and running." Four graceful ways, ranked by grace:

• Tier 1: open-source it + write the postmortem. Open the code, publish an honest retrospective: what you built, what the numbers were, why you're killing it, advice for whoever comes next. Highest-ROI way to kill — a good "failure postmortem" often brings more attention and trust than the project ever did alive. Sahil Lavingia's Gumroad retrospective is the example: the project nearly died, the postmortem made him legendary. Your "corpse" might be your best content asset. When open-sourcing, scrub secrets and user data, and write a decent README explaining "why this is unmaintained" — don't make the next person waste their time.
• Tier 2: sell it or give it away. Projects with revenue (even tiny) can list on MicroAcquire or Flippa; no-revenue-but-has-users projects can go to a peer willing to take over, on condition they keep serving existing users. The money doesn't matter much — what matters is giving the project an ending instead of letting it rot on a server.
• Tier 3: shut down elegantly. Notify users 30–60 days ahead, provide data export tools, refund pro-rata or gift lifetime discounts on your next product. The shutdown letter must be honest: "this product didn't reach sustainable scale, so I'm shutting it down" — no storytelling. Users tolerate honest shutdowns far better than you imagine; what they truly hate is "sudden disappearance." 30% of gracefully-shut-down users become seed users for your next product — that's a real observed conversion.
• Tier 4: freeze it. If you can't bring yourself to kill it, formally "freeze": write yourself a letter (why pausing, under what conditions you'd restart), archive the code, turn off paid services, set a calendar reminder 6 months out. The difference between freezing and dragging: freezing is a decision; dragging is the absence of one. The decision alone frees mental bandwidth.

Whichever tier, one mandatory step: write the postmortem — public, or at least for yourself. Answer four questions: why did you start? Which assumption was wrong? What do the numbers say? How do you avoid it next time? Killing without a postmortem is paying tuition without getting the receipt — you'll step in the same hole again.

For tier 3, five elements of a shutdown letter — just follow the template: thanks (name your earliest supporters specifically), numbers (honestly say where the product got to), reason (one sentence, no excuses), arrangements (how to export data, refund/compensation plan, shutdown timeline), what's next (what you're building now; they're welcome to follow along). Write it like a letter to a friend, not a press release. People forgive honest failure; they don't forgive vague disappearance.

A "two-week kill execution plan" to turn the decision into action: days 1–2, decide and write down why (one page, so future-you can't backslide); days 3–5, handle users — send shutdown/handover notices, open data export, set auto-replies; days 6–10, handle assets — archive or open-source the code, decide on domain renewal, cancel every paid subscription (servers, APIs, SaaS tools — this step saves real money immediately); days 11–14, write and publish the postmortem. After two weeks, the project is closed legally, financially, and psychologically. The worst state is "decided to kill, but the server's still running, subscriptions still charging, users still waiting" — that half-dead limbo costs more than never killing at all.

What the Saved Time Is Actually Worth

Let's do real math. Assume your target rate is ¥500/hour (a reasonable valuation for a senior indie developer): a "zombie project" eating 10 hours a week is 520 hours a year, worth ¥260,000. Its annual revenue to you might be ¥20,000. Every year you spend ¥260,000 buying ¥20,000 of revenue, with anxiety and self-doubt thrown in free. Once the math is done, killing isn't an emotional question — it's arithmetic.

The deeper opportunity cost is attention. Indie output isn't linear — one all-in good project can produce 10x the output of three half-hearted ones. Of Pieter Levels' 12 products, the first 11 combined earned less than a fraction of one Nomad List month. Killing is essentially trading scattered 30% energy for concentrated 100% energy — and 100% energy on a good project compounds exponentially.

My executable advice: run a "kill review" every quarter, like a financial audit. List every project you maintain; score each on three axes: core-metric growth over the last 90 days (0–10), your enthusiasm (0–10), opportunity cost (share of your time). The lowest scorer gets seriously considered for killing. And set a "kill line" when starting anything new: "if there aren't 10 paying users in 3 months, kill it." The kill line's superpower is turning "kill" from an emotional 2 AM decision into executing a pre-set rule — rules don't feel heartbreak, so you don't have to.

After the kill, don't rush into the next hole — give yourself a 30-day recovery: week 1, fully rest — no code, live like a normal human. People who've been maintaining zombies make decisions in a depleted state, and depleted-state direction picks are usually wrong again. Week 2, write the postmortem — public version out, complete version for yourself. Weeks 3–4, pick the next direction, filtered by three criteria: is anyone already paying for something similar (demand validated)? Can you ship an MVP in 6 weeks (speed validated)? If this direction fails, do you accept it (kill line pre-set)? Choosing with a "I've killed before" mindset makes you far clearer-eyed than last time — the biggest return on killing isn't the saved time; it's the upgraded judgment.

My Take: The Ability to Kill Is What Separates Indie Developers from Hobbyists

Hobbyists build projects to "make things"; indie developers build projects to "find what works." The former treats every project as a child that can't be killed; the latter treats every project as an experiment to shut down when the data says so. The deeper your feelings for a project, the more expensive your judgment becomes — too expensive to afford. Remember: an experiment's value is in falsification — a cleanly killed experiment is as valuable as a successful one.

Google is famous for killing products (hundreds lie in the Google Graveyard); internally, "killing fast is a skill." Indies should take this further: big companies need three meetings to kill something; you need one decision. Your advantage is being small and nimble — don't waste it on sunk cost.

One line to draw, though: killing isn't "running at the first hardship." The test separating "should kill" from "should persist" is whether hypothesis-testing is still advancing. If you're validating a new hypothesis monthly (new pricing, new channel, new audience) and the data talks back — even slowly — that's entrepreneurship. If you're repeating the same motions waiting for a miracle, that's procrastination. Kill projects that stopped evolving, not projects hitting setbacks. Entrepreneurship needs thick skin — but thick skin is for absorbing volatility, not for ignoring data.

One last line for your monitor: "If you don't kill mediocre projects, you'll never have time to build great ones." List your projects now, score them, find the one that should die — and kill it gracefully and publicly. You'll find you sleep unusually well that night. Because you finally gave your time back to the future. And that "future" is what you actually wanted when you quit your job (or coded through nights after work) to go indie — not "owning many projects," but "building one thing that truly works."