The real cost of a zombie project
A zombie project is one you keep alive out of habit rather than conviction — earning a little, costing a little, going nowhere. The temptation is to think it is harmless because the server bill is small. That accounting misses the real cost.
The expensive resource for a multi-product founder is not money, it is attention. Every project you maintain takes a slice of your focus: a support email here, a dependency upgrade there, a nagging sense you should be doing more with it. Multiply that across three or four zombies and you have spent a meaningful share of your week tending things that will never matter, while the one product that could actually grow gets whatever is left.
Killing a zombie is not admitting failure. It is reclaiming the attention to put behind something with a future.
Why the decision is so hard
If the numbers were obvious, nobody would agonize. They agonize because a few well-known biases make the call harder than it should be. The sunk-cost fallacy tells you the months you already poured in are a reason to continue, when they are gone regardless. Loss aversion makes shutting down feel like a loss even when continuing is the slower loss.
There is also identity: a project is a story you told the world and yourself, and killing it means editing that story. And there is hope — the launch you keep meaning to do, the feature that will surely turn it around. Hope is not a metric. The antidote is not willpower; it is a decision made against evidence you agreed on in advance, before the emotions get a vote.
The five signals that actually matter
You can drown a keep-or-kill decision in metrics. In practice, five signals carry almost all the weight: net revenue, trend, effort and opportunity cost, refund and support drag, and strategic value beyond revenue. The first four are largely visible in your numbers; the fifth is judgment you supply. Weigh them together and the call usually makes itself.
None of the five requires a spreadsheet full of derived ratios. They are the questions a thoughtful founder would ask anyway — is it making real money, is that number going up or down, what is it costing me, is it causing problems, and does it matter for reasons beyond its own revenue. The value is in asking them deliberately, and in the same way for every product, rather than letting the loudest project or the newest idea capture your attention by default.
Signal 1: Net revenue, not gross
Start with what the product actually earns after refunds, disputes, and fees — net revenue, not the gross figure that flatters every dashboard. A product doing $800 gross but bleeding $300 to refunds and chargebacks is a very different patient than one doing $500 clean.
Judge the absolute number against your own bar. What counts as alive is personal — for some founders $200 a month of near-passive net revenue is a keep; for others anything under a grand is noise. The point is to judge on the money that really lands, and to set the bar honestly rather than moving it to justify whatever you already want to do.
Signal 2: Trend, not snapshot
A single month is a photograph; the decision needs the movie. A product earning $400 and climbing is a completely different case from one earning $400 and sliding, even though the snapshot is identical.
Look at the last several months of net revenue and ask which direction the line points and how steeply. Flat can be fine for a genuinely passive product. Declining, especially accelerating decline, is the clearest kill signal there is. Rising — even from a small base — is often reason enough to move something from Kill to Watch and give it another quarter.
Signal 3: Effort and opportunity cost
Revenue is only half the ratio; the other half is what the product costs you in time and attention. A tool that earns $300 and needs nothing is worth keeping. A tool that earns $600 but eats a day a month in support and maintenance may be costing you more than it makes, once you price your time and the projects that day could have gone to.
Be honest about opportunity cost specifically. The question is never just whether this product is worth keeping in isolation. It is whether this attention would do more somewhere else. For a founder with one clear winner, almost any attention pulled off it is expensive.
Signal 4: Refunds, disputes, and support drag
High refund and dispute rates are more than lost revenue — they are a signal about fit and a tax on your time and reputation. A product people buy and then charge back is telling you something, and each dispute carries fees and admin on top.
Support load works the same way. A small product generating an outsized share of your support inbox is quietly expensive even if the revenue looks fine. When you tally the keep-or-kill case, count this drag as a real cost, because it is one.
Signal 5: Strategic value beyond revenue
Not everything worth keeping pays its own way directly. A product might be a loss leader that feeds your main funnel, a learning vehicle, a credibility piece, or an audience you can sell to later. These are legitimate reasons to keep something the raw numbers would kill.
The discipline is to name the strategic reason explicitly and honestly. It supports the main product by driving a real number of signups a month is an argument. It might be useful someday is usually hope wearing a strategy costume. If you cannot state the strategic value in a concrete sentence, it probably is not there.
Keep, Watch, or Kill: turning signals into a call
Three buckets are enough. Keep is a product carrying its weight: net revenue above your bar, flat or rising trend, effort in proportion, no reason to reconsider. Double down here — these are where more attention compounds.
Watch is the ambiguous middle: modest revenue, uncertain trend, or a real but unproven strategic reason. Give it a defined window — a quarter, say — and a condition: if the trend does not improve by then, it drops to Kill. The trap is letting things live in Watch forever; a watch without a deadline is just a slow keep.
Kill is a product below the bar with a flat-or-declining trend and no strategic case. The evidence has spoken. What remains is the hard part: acting on it.
How to actually kill a project
Deciding to kill is not the same as killing, and founders stall on the execution as much as the decision. Killing well is mostly about your existing users and your future self. Give paying customers honest notice, stop new signups, and offer a wind-down: a refund window, an export, or a migration path if one exists.
Then reduce it to the smallest maintainable state or shut it off entirely, cancel the dependencies and subscriptions it carried, and — importantly — write down why you killed it. Future-you will be tempted to relaunch the same idea; a short post-mortem is a gift to that person. Done cleanly, a kill is not a funeral. It is closing a tab so you can focus on the one that is open for a reason.
Run the numbers before the feelings
The framework only works if you gather the evidence before you sit down to decide, because the moment the decision feels personal, the numbers become negotiable. Pull each product's last six months of net revenue, its refund and dispute totals, and an honest estimate of the hours it costs you in a typical month. Write them down where you can see them side by side.
Seeing the whole portfolio at once changes the conversation. A product you were sentimental about looks different next to the one quietly out-earning it with a tenth of the effort. Comparison, not introspection, is what breaks the tie — which is exactly why a single view across products matters more than any one product's dashboard.
Kill to focus, not to tidy
There is a failure mode on the other side of indecision: killing things for the wrong reason. The goal is not a tidy portfolio or the satisfaction of pruning — it is concentration of effort. A project earning steady, near-passive net revenue with almost no upkeep is not clutter to be cleared; it is a small annuity, and killing it out of a tidiness impulse is its own mistake.
So the test is always relative to attention. Keep the passive earners that cost you nothing. Kill the ones that cost real attention and are not returning it. The discipline is to act on the demanding zombies while leaving the quiet, self-sufficient survivors alone — not to burn the whole garden because a few plants died.
When the honest answer is not yet
Sometimes the framework returns a genuine maybe, and forcing a Keep or Kill would be false precision. A product might be too young to judge — a launch that has not had time to find its trend — or waiting on one concrete, scheduled event that will settle it. That is what Watch is for, but only under two conditions: the event is real and dated, and you have written down what result moves it to Keep versus Kill.
The failure is the open-ended maybe: keeping something alive on the strength of a launch you have been about to do for six months. If the deciding event keeps slipping, that slipping is itself the signal. A project you cannot bring yourself to schedule the make-or-break moment for has usually already been decided; you just have not said it out loud.
What changes when you make it a habit
A keep-or-kill call is not a one-time purge; it is a review you run on a cadence — monthly or quarterly. The first pass is the hardest because there is usually a backlog of decisions you have been avoiding. After that it becomes maintenance: a quick look at which products moved between Keep, Watch, and Kill since last time, and a small number of deliberate choices.
Founders who run this regularly report the same thing: not that they kill more projects, but that they stop starting things they would obviously kill, and they double down sooner on the ones that are working. Seeing the portfolio honestly, on a schedule, makes you a better allocator of your own attention — which is the entire point of running more than one thing without drowning.
How VerifiedMRR turns this into a score
This framework is exactly what VerifiedMRR automates. It reads each product's real numbers — net revenue, refunds and disputes, recent activity, and trend — from your connected payment accounts, read-only, and turns them into a Keep, Watch, or Kill label per product, updated as the data changes.
It deliberately scores the parts a number can capture and leaves the strategic-value judgment to you, because that part should be yours. The result is that the four measurable signals are always current and on the table, so the keep-or-kill conversation starts from evidence instead of guilt — and you spend your decision on the one call a machine should not make.
