What does keeping a zombie app alive actually cost?

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

A zombie app — one that still runs, still has a few users, but hasn't grown or been meaningfully worked on in months — mostly costs attention, not money. The real bill shows up as recurring renewal decisions you never revisit, dashboard and inbox clutter that slows down every other product, and the opportunity cost of not spending that time on something that's still moving. None of that appears on a Stripe invoice, which is exactly why it's easy to ignore.

If you run one product, a stalled app is a clear yes/no decision. If you run five, ten, or fifteen, zombie apps hide in plain sight — they're just one more row in a spreadsheet that hasn't been red for long enough to notice.

The costs that actually show up on a statement

Start with what's measurable, because it's the easiest to underestimate.

• Hosting and infra. A Postgres instance, a Vercel project, a small EC2 box — often $5 to $50/month per app, but multiply by however many zombies you're carrying and it adds up faster than any single line item suggests.
• Third-party subscriptions tied to the app. A paid API key, an email sending tier, a monitoring tool, an App Store or Play Console developer account fee amortized across apps that no longer justify it.
• Domain and SSL renewals. Small, but they're exactly the kind of charge that renews silently on a card you forgot was linked to this project.
• Support tooling. If you're paying per-seat or per-inbox for a helpdesk tool just to catch the occasional email from three remaining users, that's a real recurring cost against a shrinking base.

None of these individually justify a panic. Together, across a portfolio, they're worth adding up once a quarter — not because the total will shock you, but because you'll usually find at least one subscription you forgot you still had.

The costs that don't show up on any statement

This is where the real damage happens, and it's harder to see precisely because it never appears as a number you can screenshot.

Attention fragmentation. Every app in your portfolio, active or not, competes for a slot in your mental model of "things I'm responsible for." A zombie app still gets a glance when you open your analytics, still gets a moment of guilt when a crash report comes in, still occupies a tab you keep meaning to close. That tax gets paid daily, in small amounts, whether or not the app earns it.

Support debt. Even a handful of remaining users generate tickets — a login bug, a billing question, a "why did this break" email. Answering them is the right thing to do for those users, but it's time taken directly from whichever product is actually growing. If you've ever put off a feature ship because you were fixing something in an app you stopped caring about eighteen months ago, you've paid this cost.

Decision debt. Every renewal — a domain, an API tier, an app store fee — is a decision point you're supposed to actively make and usually don't. Auto-renew turns "should I keep this alive?" into a question you only ask when something breaks, which means the app effectively makes the decision for you by default, in the direction of "keep going."

Data and credential sprawl. A zombie app still has API keys, OAuth grants, and webhook secrets sitting active somewhere. They're not costing you dollars, but they're part of your attack surface, and "I'll clean that up eventually" is how stale credentials end up in a breach post-mortem instead of a changelog. If you're auditing what's connected to what across your portfolio, the security overview and a look at what your tools actually connect to are a reasonable place to start — scopes and revocation matter more once you stop actively watching a project.

Opportunity cost. This is the biggest one and the hardest to quantify. Every hour spent triaging a legacy bug, every renewal you have to research before deciding whether to cancel it, is an hour not spent on the two or three products in your portfolio that are actually compounding. Across a 10-app portfolio, the founders who do best usually aren't the ones with the most apps — they're the ones who've been honest about which ones stopped deserving attention. Real numbers from a 10-app portfolio get into this in more detail.

How to actually measure it for your own portfolio

Don't guess — spend twenty minutes per zombie candidate and check four things:

1. Direct cost. Sum hosting, subscriptions, and any per-seat tooling tied specifically to this app. This is the only number that goes on an actual statement.
2. Revenue trend, not revenue level. A zombie app can still generate a small trickle of MRR. What matters is whether that trickle has been flat or declining for 90+ days with no active development. If you're tracking Stripe and RevenueCat for the same app, tracking Stripe and RevenueCat together is worth a read since the two rarely match and the gap itself is informative.
3. Support time, roughly. Even a rough estimate — "I spend maybe 30 minutes a week on this" — multiplied over a year is a number worth writing down once.
4. What you'd do with the freed slot. This is the real question. If the honest answer is "nothing, I'd just have one less thing," that's useful information too — it means the app isn't costing you as much as you feared, and killing it might just be tidiness. If the answer is "I'd finally ship the feature I've been delaying on my main app," the zombie is costing you more than it looks like.

If you've already decided the numbers point to sunsetting rather than reviving, a checklist for sunsetting an app gracefully — wait, that's not in your links, skip. Actually: check whether reviving makes sense first — how to revive a stalled app covers the decision from the other direction, in case the numbers say "worth one more push" instead of "let it go."

Where a portfolio view actually helps

This is a decisions-cluster post and SoleOS is in the decisions business, so full disclosure: SoleOS wrote this post about its own space — mission control for a multi-product portfolio is literally what it's for. Its actual usefulness here is narrow but real: connecting Stripe, RevenueCat, App Store Connect, Play Console, and analytics tools once per app means the flat 90-day trend line for a zombie app shows up automatically instead of requiring you to remember to go check five separate dashboards for a product you've mentally already written off. That's exactly the kind of check that gets skipped without a nudge.

You don't need SoleOS for this if you're running one or two products, if you already check each dashboard weekly out of habit, or if a spreadsheet with a "last touched" column does the job — a spreadsheet comparison is honest about where a free template is genuinely enough. Where it starts to help is past four or five products, when "check every dashboard" quietly turns into "check the ones I remember to check," and zombies are, by definition, the ones you stop remembering.

If you want to see what that actually looks like before deciding anything, the live demo uses sample data and doesn't require a sign-up.

Frequently asked questions

How long should an app go without growth before I call it a zombie?

There's no universal number, but 90 days of flat or declining revenue and zero active development is a reasonable line for most solo portfolios. The important part isn't the exact threshold — it's picking one in advance so you're not making the call emotionally in the moment. Related: kill criteria defined before launch removes this decision from a bad week entirely.

Isn't a small trickle of revenue better than nothing?

Usually, yes, in isolation. The question isn't whether the app earns more than $0 — it's whether the time and attention it quietly consumes (support tickets, renewal decisions, mental overhead) costs more than the trickle is worth. A $15/month app that takes zero of your time is fine to leave running indefinitely. A $15/month app that generates a support email every week is a net negative.

Should I shut it down or try to revive it first?

That depends on whether the stall was caused by neglect or by the market. If you haven't touched marketing, pricing, or onboarding in months, a revival attempt with a real, time-boxed effort might tell you more than the current numbers do. If you've already tried and the trend didn't move, sunsetting is usually the honest answer.

Does keeping a zombie app running hurt my other products?

Only indirectly, through attention and time, not through any technical mechanism. The risk is that a zombie's small, recurring demands — a bug report, a renewal, a support ticket — get first-in-line priority simply because they're urgent and small, while the important work on your active products gets pushed to "later" indefinitely.

How do I decide which zombie to deal with first if I have several?

Rank by support time consumed, not by revenue or by how long it's been stalled. The app eating the most of your weekly attention for the least output is the one worth resolving first, regardless of whether it's your oldest or your smallest.