When to kill a side project: the numbers that matter

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

Kill a side project when its core metric has been flat or declining for months despite real effort, when nobody will pay for it at any price, when the addressable market is too small to matter, or when it's quietly eating attention your best project needs more. The decision should come from a spreadsheet, not a feeling — feelings say "just one more sprint," numbers say whether that sprint has a reasonable chance of changing the outcome.

Most solo founders don't kill projects too early. They kill them too late, or never formally kill them at all — they just stop looking. An undead project still costs you: a dependency to update, a support email to answer, a tab of guilt you avoid opening. Deciding on evidence turns that guilt into an actual choice.

Decide on evidence, not emotion

Emotional reasoning sounds like: "I've put so much into it," "it might turn around," or "what if I quit right before it worked." None of those are measurements.

The evidence-based version asks three questions instead:

• Is the trend moving, and which way? Look at a rolling three-to-six-month trend in revenue, signups, or active usage — not a single good or bad month.
• Is it responding to your effort? A flat line despite real shipped changes is a much stronger signal than a flat line during a month you ignored the project.
• What would "working" look like, and how far are you from it? If you can't state a number, you can't tell whether you're close or nowhere near.

Once you run more than two or three products, this comparison is easy to lose track of by memory — which is the case for keeping some kind of portfolio view, so "flat for months" is something you can see rather than reconstruct. Running one or two projects, a spreadsheet you actually update does the same job; you need a habit of looking, not a tool.

The kill signals that actually matter

A handful of signals are hard to argue away:

• Flat or declining core metric for 3+ months despite real effort — not "I didn't touch it" flat, but "I shipped fixes and marketing and it still didn't move" flat.
• No willingness to pay at any price. If you've tested multiple price points, or asked prospects directly what they'd pay, and the answer is consistently "nothing," that's a demand problem, not a pricing one.
• A market too small to matter. Even a fully successful version — every plausible user converted — doesn't add up to revenue worth your time. Estimate that ceiling honestly.
• Unit economics with no credible fix. If it costs more of your time or money than it returns, and no lever changes that, the math is telling you something.
• Opportunity cost. Every hour here is an hour not spent on the project that's actually growing. A large, persistent gap against your best-performing project is a kill signal on its own.

Usually it's two or three together — flat growth, no payment signal, a shrinking share of attention relative to what it earns — that make the case, not any one alone.

The sunk-cost fallacy, named plainly

The sunk-cost fallacy is believing past investment justifies future investment. It doesn't. The nights building the auth flow, the App Store review you survived — none of that is a reason to keep going. The only relevant question is: given where the project stands today, is continuing the best use of your next hour? Sunk time and money are real costs already paid, but they can't be recovered by spending more, only by changing course.

A useful trick: describe the project's current numbers as if a stranger were pitching it to you cold. Would you start it today? If not, the history isn't evidence — only the present state is.

Stalled but salvageable vs. genuinely dead

Not every flat project should die. The difference is whether the flatness comes from something fixable and untried, or something structural.

Stalled but salvageable: you haven't actually marketed it, pricing has never been tested, onboarding is clearly broken and fixable, or you paused for unrelated reasons rather than market rejection. There's an untried lever with a specific hypothesis attached.

Genuinely dead: you've tried the obvious levers — price, positioning, a real marketing push — and the response stayed flat. Or the market is confirmed too small no matter what. Or it needs time, budget, or a skill you don't have and won't get. With no untried lever left, "salvageable" is wishful thinking dressed up as strategy.

The fastest way to tell them apart: before you look at the numbers, write down what result keeps you going and what result makes you stop. Can't write that sentence yet? You're not ready to decide — write it first, then look.

Give it a fair trial and a decision date, first

The opposite failure is killing too fast, off one bad week, or because a shinier idea is competing for attention. Fix that by setting a decision date up front — ideally when you launch a change (a repricing, a redesign, a new channel), not after you've already started resenting the project.

Pick the metric, the threshold that counts as success, and the date — 60 to 90 days is usually enough. Write it down somewhere you'll see again. When the date arrives, judge the number you committed to, not whichever feels most flattering that week. Hit the bar and set the next date; miss it, and that's your evidence — not grounds to negotiate another quarter.

Options besides deleting it

"Kill" doesn't have to mean delete the repo and the domain. Once you've decided a project isn't worth further investment, you still have choices about how it ends:

• Sunset gracefully. Announce an end date, give users an export path, and shut down cleanly instead of leaving broken links and stale billing.
• Raise the price and let it self-select. A small base of happy users but no growth can become low-maintenance, profitable-enough revenue — or it thins to nothing, which is itself useful information.
• Sell it. Even modest revenue or a working codebase has a buyer somewhere; a small acquisition beats deletion for the same effort.
• Open-source it. If the idea has value without a business behind it, releasing it costs you almost nothing.
• Hand it off. A co-founder, freelancer, or maintainer more excited about this niche can keep it alive without it being your job.

Each of these ends your obligation to actively grow the project without necessarily ending its existence.

What killing well buys you

The point isn't tidiness. Every project you keep half-alive out of guilt quietly taxes the one that's working. Killing, sunsetting, or handing off a stalled project frees your best hours for whatever has the highest return right now. That's why portfolio triage matters more as the project count grows — see how to manage multiple side projects for the broader operating model this fits inside.

Disclosure: this guide is published by SoleOS, portfolio-triage software for people running many products, so we have an obvious stake in this topic. You don't need SoleOS to make this call well — a spreadsheet with a revenue and activity column per project, reviewed on a schedule, gets you most of the way there. A tool earns its keep once "reviewed on a schedule" keeps not happening — see the connectors that pull the numbers automatically.

Frequently asked questions

How long should I give a side project before deciding?

Set the window before you start measuring — 60 to 90 days usually separates a real trend from noise for metrics like signups or MRR. Shorter windows work for high-traffic products; longer ones suit anything seasonal or B2B.

What if the project makes a little money but isn't growing?

It depends on the effort required to keep it there. Near-zero-maintenance revenue is worth keeping as is, or worth a price increase. If it demands ongoing support to stay flat, compare that time against what the same hours return on your best project.

Isn't killing a project a waste of everything I built?

The building already happened — that cost is sunk regardless of what you do next. The only real decision is whether more of your time is better spent here or elsewhere, and the sunk cost can't answer that. If the code or idea has value on its own, selling or open-sourcing it recovers something without asking you to keep investing.

How do I know if a project is stalled versus genuinely dead?

Ask whether there's a specific, untried lever left — an untested price, an unused channel, a known onboarding fix — with a concrete reason to believe it would move the number. If yes, it's stalled, worth one more trial with a decision date. If you've tried the obvious levers and the response stayed flat, it's dead, and more effort won't change the verdict.

Should I tell my users before shutting a project down?

Yes, whenever there are active or paying users — a real end date, a data export path, enough notice to move on cleanly. How you sunset one project is what users of your other products will assume about how you'd treat them. The same trust logic shows up in how to reduce SaaS churn — a graceful ending is a retention decision in reverse.