The most expensive line in a startup’s budget is often the one nobody talks about: the app that stopped growing eighteen months ago but keeps generating invoices.
Most founders understand launch costs. Few understand maintenance costs. And almost none understand the true cost of a dormant product — one that isn’t growing, isn’t generating meaningful revenue, but isn’t quite dead enough to kill. That ambiguity is where money quietly disappears.
My position is simple: the ongoing cost of keeping a mobile app alive is significantly underestimated by most teams, and that underestimation causes companies to hold zombie products years longer than they should. The cost isn’t just financial. It’s organizational.
The Infrastructure Bill Never Goes to Zero
A mobile app that nobody is downloading still has users. Maybe a few hundred, maybe a few thousand, depending on how successful the launch was. Those users generate requests, store data, and trigger push notifications. The backend doesn’t know the app is dying.
Cloud hosting, database storage, CDN costs, third-party API subscriptions, monitoring tools, crash reporting services — these don’t scale to zero. Many have floor pricing regardless of usage. If you built on Firebase, AWS Amplify, or a similar managed stack, you know this: the base cost exists whether you have ten users or ten thousand.
For a reasonably well-architected small app, infrastructure costs in the range of a few hundred dollars a month are common even with negligible traffic. Over two years, that’s money that could have funded something productive.
Compliance and Stores Demand Ongoing Attention
Apple and Google are relentless about platform policy updates. An app that isn’t actively maintained will eventually fail App Store review, get flagged for outdated SDK usage, or simply break when a new OS version drops. Apple has been explicit about this: apps that haven’t been updated in a meaningful period are subject to removal from the store.
This creates a treadmill nobody signed up for. To keep an app technically available — not improved, just available — someone has to update dependencies, test against new OS versions, and occasionally rewrite small sections of code to satisfy platform requirements. That work takes engineering time. Engineering time has a cost whether it’s a full-time employee or a contractor brought in for two days every six months.
The SDKs your app depends on also march forward. Authentication libraries, analytics packages, payment processors — they deprecate old versions and stop issuing security patches. An app that never gets touched becomes a security liability, which is a different category of cost entirely.
The Opportunity Cost Is the Real Number
The cash costs are real but survivable. The opportunity cost is what actually kills companies slowly.
Every hour an engineer spends keeping a dormant app compliant is an hour not spent on the product that might actually grow. Every conversation a founder has about whether to finally shut down the old app is a conversation not happening about the new one. The cognitive load of managing a zombie product — the server alerts, the support emails from users who somehow still found it, the quarterly decision to defer the shutdown decision — accumulates.
This connects to something worth naming directly: context-switching feels free until you measure it. A dormant app is a permanent context-switch tax on every person who knows it still exists and might need attention. It sits in the back of the engineering team’s mind. It occupies a Slack channel. It generates noise.
The Sunk Cost Trap Keeps Apps Running Too Long
The reason companies hold zombie products longer than they should is almost always psychological. The app cost real money to build. Shutting it down feels like admitting that money is gone. So the company pays a smaller ongoing cost, month after month, to avoid confronting the larger loss.
This is textbook sunk cost reasoning, and it’s worth being blunt about: the money spent building the app is gone whether or not the app keeps running. The only question is whether you will continue spending money to maintain an asset that generates no return.
Shutdown has real costs too — migrating or deleting user data, notifying users, handling the App Store removal process, potentially managing contractual obligations to enterprise customers. Those costs are finite and one-time. Maintenance costs are infinite and recurring.
The Counterargument
Some apps genuinely justify minimal-maintenance operation. A simple utility with no backend, no third-party dependencies, and a loyal niche audience might cost almost nothing to keep alive and generate steady revenue from past downloads. If an app generates more in monthly subscription revenue than it costs to maintain, the math is obvious: keep it running.
There’s also a legitimate argument that dormant apps sometimes serve as customer acquisition assets. Old content still ranks. Old apps still appear in App Store searches. An app in an adjacent category to your current product might still drive some discovery.
But these arguments apply to a small minority of cases. For most dormant apps, the revenue is negligible, the discovery value is minimal, and what remains is mostly inertia dressed up as strategy.
The Decision Most Teams Never Make
The companies that handle this well treat app shutdown as a product decision with a defined process, not a conversation they keep deferring. They set explicit criteria: if the app falls below a threshold of active users, or if monthly revenue drops below monthly infrastructure cost, the shutdown process begins on a fixed timeline.
As the real cost of keeping a software product alive makes clear, the cost of inaction is rarely zero. For mobile apps specifically, the platform constraints mean inaction eventually becomes forced action under worse conditions.
A mobile app that nobody is downloading is not a free option on a future revival. It is a recurring expense with no upside, staffed by a team whose attention it will keep stealing until someone finally makes the call. Make it sooner.
