What is a zombie app, and how do I find mine?

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

A zombie app is a product that's still live, technically working, and maybe even bringing in a trickle of revenue — but it hasn't grown in months, almost nobody actively uses it, and it still eats your maintenance time, your hosting bill, and your attention every time it crosses your mind. You find yours by looking for flat lines over several months, not a bad week or a slow quarter. If a product is quietly costing you more focus than it earns you money, it's a zombie, whether or not it's technically "failing."

What actually separates a zombie from a normal quiet product

Not every low-traffic app is a zombie. A product you launched a couple of months ago with no growth yet isn't one — it's early, and early is normal. A product you deliberately built to run on autopilot isn't one either, if you're genuinely fine with that and it isn't generating support load or breaking. The zombie category is the middle: not new, not intentionally dormant, just stuck. It launched, found a small user base, growth flattened, and instead of a clean decision to grow it, sunset it, or run it quietly, it just kept existing in the background.

Three things usually define it: it's still live and maybe earning a little, so it never triggers an obvious "this failed" moment; it's flat rather than collapsing, which makes it easy to ignore; and it still costs you something — hosting, a paywall or auth subscription, a dependency needing a security patch, a support inbox you still check. Small costs individually, but they add up once there are several zombies, not just one.

How to find yours by the numbers

You don't need a fancy dashboard to tell a zombie apart from a healthy product — you need a few trends pulled over a long enough window that noise cancels out.

MRR trend, six months, not thirty days. Pull revenue for each of the last several months and look at the shape, not the latest figure. What matters is the trajectory: has it been essentially the same number, give or take, for half a year, or is it moving in a direction? Two products can share an identical MRR today and be in completely different situations depending on where that number came from.

Traffic and signups, same window. Do the same for organic search visits, referral traffic, or app store impressions, plus new signups or installs per month. A product can have stable revenue from existing subscribers while its funnel for new users has quietly gone to zero — that's a zombie with a countdown timer, since existing subscribers churn eventually and nothing replaces them.

Active usage relative to paying accounts. Compare how many people you bill against how many actually opened the product recently. A wide and growing gap between paid seats and active sessions is one of the clearest zombie signals there is — the product isn't delivering ongoing value even to the people funding it, they just haven't gotten around to cancelling.

Support burden relative to revenue. Track the hours you spend on a product's support inbox, bug reports, or store reviews in a typical month, and put a rough hourly rate on your time. If that number is close to or higher than what the product pays you, the math doesn't work.

None of these need to be exact — the point is a real trend, not a vague feeling that "that one's probably not doing much."

There's also a signal no spreadsheet captures: whether you avoid opening the project. If you dread checking a certain app's analytics, put off its dependency updates, or feel relief when a week passes without thinking about it, that avoidance is data. Founders are usually more honest with their gut than their dashboard — if you're steering clear of a product, part of you has likely already decided it's not worth the attention, and just hasn't made it official.

The hidden cost is attention, not hosting bills

The instinct is to price a zombie app by its infrastructure cost — a few dollars a month for hosting, maybe a small bill for auth or email. That's real but usually small. The bigger cost is what it does to your focus: remembering the product exists, deciding whether this week's spare hour goes to your growing app or your stalled one, carrying the low-grade guilt of an unanswered support ticket. Multiply that by several zombies sitting alongside the products you actually want to be building, and the tax on your attention often outweighs the tax on your bank account. That's the core problem with running more than one product without a system for triage — see our guide on managing multiple side projects without losing your mind for how that cost compounds across a whole portfolio, not just one app.

Your four honest options once you've found one

Finding a zombie doesn't obligate you to kill it. It obligates you to make a deliberate choice instead of letting inertia make it for you.

Revive it, on purpose. If the flat numbers hide a fixable problem — a broken onboarding step, a pricing page nobody sees, an abandoned marketing channel — a focused stretch of work can sometimes restart growth. The key word is deliberate: pick one specific change, one metric, and a firm deadline. If it doesn't move by then, treat that as your answer.

Sunset it gracefully. Some zombies aren't worth reviving — the market moved on, or you no longer want to run that kind of product. Give users fair notice, export their data, and turn it off cleanly rather than leaving it to decay unmaintained. Our guide on when to kill a side project walks through how to make that call without burning goodwill.

Sell it. A product with steady, even flat, revenue and low support load can be a reasonable acquisition for someone who wants a smaller, calmer project than you do. Even a modest sale price often beats the ongoing attention cost, and converts a mental liability into cash.

Keep it, consciously, as passive income. This is legitimate — but only if it's actually passive: near-zero support tickets, no pending security work, no recurring emotional weight. If you're justifying "I'll just leave it" while dreading its support inbox, that's not passive income, that's a zombie wearing a disguise.

How a portfolio view helps you catch these before they pile up

Zombies are easy to miss because they don't look bad in any single dashboard — they look mediocre in several dashboards you check separately, if you check them at all. A portfolio view puts each product's MRR, traffic, and activity trend side by side so a flat line is obvious next to a growing one, instead of buried in a tool you only open for that one app once a month.

SoleOS publishes this guide, and this is the pattern SoleOS is built to surface — a portfolio dashboard for solo founders running several products at once. It connects to your existing tools and data sources and flags products that have gone quiet, so you're not relying on memory or dread to notice. See how that looks with a live demo rather than take our word for it.

That said, you don't need SoleOS, or any dedicated tool, for this. If you're running one or two products, a spreadsheet with a row per app and a column per month for MRR, traffic, and active users will surface the same flat lines just as clearly — the tool matters far less than actually looking at trailing months instead of today's snapshot.

Frequently asked questions

How long does a product need to be flat before it counts as a zombie?

There's no universal cutoff, but three to six months of essentially unchanged MRR, traffic, and active usage is a reasonable threshold — long enough to rule out normal month-to-month noise, short enough to catch it before you've sunk another year of attention into it. Look at the trend across that window, not any single data point inside it.

Isn't a zombie app just a failed product I haven't admitted is dead?

Not quite. A failed product usually has a clear signal — it's losing money, breaking for users, or actively declining. A zombie is stealthier: the numbers are stable enough that nothing forces the decision, which is exactly why it can sit unaddressed for years. The failure isn't in the product's performance, it's in never getting a deliberate decision applied to it.

Should I sunset a zombie app that's still profitable?

Not automatically. Profitable-but-flat is one of the honest outcomes, not a problem by default. The test is whether the support burden and mental overhead are genuinely low. If a product nets you real money and rarely needs your attention, keeping it running is fine — just make sure that's a decision you made, not one you're avoiding making.

Can a zombie app come back to life?

Sometimes, but only with a deliberate intervention, not by leaving it alone longer. Revivals that work usually target one specific, diagnosable problem — a broken signup flow, an outdated integration, a pricing change — rather than a vague hope that traffic will pick back up. Set a defined test and a deadline; if the metric you're trying to move hasn't moved by then, that's useful information in itself.