~12 min read · You paid the final invoice. The app is shipped. It's stable. Why keep paying? Here's what actually happens — month by month, year by year — to an app you stop maintaining. The timeline is more predictable than most owners realize, and the math at the end is brutal.
There are two moments in the life of an app when most owners stop paying for maintenance, and both of them feel reasonable at the time.
The first is when the app feels stable. The launch is over, the obvious bugs have been fixed, users seem happy, and there's nothing visible that needs attention. The buyer thinks:
we're past the building phase; we don't need to keep paying engineering rates for an app that's basically working.
They reduce the monthly retainer to zero. The developer agrees, perhaps reluctantly. Maintenance ends.
The second is when something happens — a budget cut, a strategic pivot, the founder runs out of money for a few months, a key relationship ends — and maintenance gets paused. The plan is to come back to it later, when things settle down.
Both of these moments end the same way. The app goes silent. Nothing changes. For a while, nothing visible happens at all.
This is the most misleading part. The decay of an unmaintained app is quiet, then sudden. For months, the app looks the same as it did the day you stopped paying. Then a switch flips somewhere, and you discover that the app has been quietly disintegrating the entire time, and the cost to bring it back is no longer maintenance — it's resurrection.
This article is about the timeline of that disintegration. What breaks first, what breaks second, what breaks fatally. And the math at the end, which is the part that should make every app owner uncomfortable enough to do something about it.
Month 1 to 3: Nothing Visible
The first quarter after the last invoice is silent. The app keeps working. Users keep using it. The team's brain space, freed from the project, moves on to other things.
In this period, the only thing that changes is that the institutional knowledge starts to leak.
The developer who built the app has now moved on to other projects. The specific things they had in their head — why a particular file is organized the way it is, which dependency was added for what reason, what the rollback procedure was for the production database — are no longer being refreshed. They start to fade.
Three months is short enough that most of this knowledge is still recoverable. If you brought the developer back in month three with a small fix, they'd remember most of what they needed. The decay is real but quiet.
There's also a less visible thing happening: the ecosystem around your app is moving. The frameworks you're using are releasing new versions. The platforms (iOS, Android) are issuing point updates. The dependencies your app uses are publishing patches. None of this affects your app yet — but the gap between the world your app was built in and the world your app now runs in is widening, by a few millimeters a week.
Month 6: The First Warning
Somewhere around month six, the first concrete event happens.
It might be a notification in your Apple Developer or Google Play Console account: a framework you're using has been deprecated, and your app will need to migrate before some future date. It might be a security advisory: a library buried inside your app has a known vulnerability, and you'll need to update. It might be a small change in iOS or Android that breaks one specific behavior in your app — usually something minor, like a permission flow that no longer prompts properly.
The warnings at month six are easy to ignore. They have future dates on them. We'll need to migrate by August 2027. Eight months away. Plenty of time.
The trouble is that nobody is now responsible for tracking these warnings. The developer is gone. The buyer doesn't check Apple Developer or Google Play Console emails the way an active project's team does. The notifications go into a folder. The deadline gets quietly closer.
This is the moment most owners could still recover cheaply. A few hours of an engineer's time, applied at month six, would handle each warning as it arrives. The total cost is small. The problem is that the warnings don't feel urgent yet, so they don't get the attention they need.
Year 1: The Compliance Deadline Lands
By month twelve, at least one of those deferred warnings has matured into a real deadline.
Most commonly, it's the target SDK requirement. Both Apple and Google require your app to be built against a recent version of their development tools — currently, within roughly the last year. If your app was built against a version that's now too old, the store will refuse new submissions and may eventually remove the app from search results entirely.
This is where many owners discover, for the first time, that maintenance isn't optional. The app store sends a final notice: your app will be removed from the store in 60 days if you don't update. The owner panics. They call the original developer. The developer is busy with other projects, and quoted timeline for the update is several weeks. The cost is no longer "a few hours of engineering" — it's a small project, because the developer needs to re-familiarize themselves with the codebase, update all the deprecated APIs at once, and re-test the app.
At month twelve, the cost of catching up is maybe 2–3x what monthly maintenance would have been over the year. Painful, but recoverable.
Owners who pay this bill, and who use the moment to re-establish a maintenance cadence, recover entirely. Owners who pay this bill, fix the immediate problem, and then stop paying again are now on a doubled-down path toward year two.
Year 1.5: The Build Doesn't Work Anymore
Somewhere between month fifteen and month eighteen, a more uncomfortable thing happens.
A user reports a bug. The developer tries to reproduce it. They go to set up the project on their current machine — they got a new laptop sometime in the last year, or their existing one has been updated several times — and the project doesn't build.
It's not that the code is wrong. It's that the build environment has changed. The version of Xcode the project was set up with is no longer installable on the current OS. The version of the Flutter or React Native SDK the project uses has been deprecated. The version of Java the Android build requires has been replaced. The specific dependencies the project pinned to are no longer available from their original sources.
This is the moment where the cost of reviving the app starts to multiply. The developer can't just fix the bug; they have to first rebuild the ability to work on the project at all. This means upgrading the framework version (which itself usually requires fixing dozens of places where the API changed), updating Java/Swift/Kotlin to match, finding replacements for now-broken dependencies, and re-testing everything.
A week's worth of "we'll just look at it" turns into a month of "we need to bring the project current before we can do anything."
This work is the kind of work no owner wants to pay for, because there's nothing visible at the end of it. The app, after all this engineering, behaves exactly the same as before — except now it can be developed again. The owner sees a large invoice for "no change." But there was a change: the project went from unable to be worked on to able to be worked on. That transition has a cost, and it gets larger the longer the project sits.
Year 2: The Reviews Start to Fall
Year two is when the public-facing decay begins.
Up to this point, the decay has mostly been internal — the project gets harder to work on, the warnings pile up, the compliance deadlines pinch. The users haven't really noticed.
In year two, that changes. A new iOS or Android version ships, and your app — which hasn't been tested against current OS releases for over a year — develops a bug. Maybe it's small at first. The screen rotation breaks on a specific device. The permission dialog flashes weirdly. A push notification doesn't display properly. Individually, none of these are catastrophic. Collectively, they erode the user experience.
The users notice. Some of them write reviews. Some of them open support tickets. Some of them just uninstall. Your one-star reviews start to outnumber your five-stars on the new updates.
If the app was on a steady 4.5-star rating, it may now be trending toward 4.2. Then 3.9. Below 4.0 is a different category of app, and the store's algorithm treats it differently — fewer recommendations, lower search rank, slower organic growth. The decay is no longer invisible. It's affecting the business.
The owner now wants to fix things. They go back to the developer. The developer has, by now, been gone for two years. They might be available, they might not. If they are, the quote is meaningfully larger than it would have been at any earlier point — because everything that should have been done is now needed at once. If they aren't, the owner is hiring a new developer to inherit a codebase that has been steadily decaying.
That new developer's first month, as we describe in your developer left — what happens next, is the stranger tax. The cost of someone learning a codebase they didn't build. In an unmaintained codebase, that stranger tax is significantly higher than in a healthy one.
Year 2.5: The Security Advisory
Somewhere in the second half of year two, a security advisory hits.
A dependency your app uses — one of the dozens of libraries that make modern apps possible — has a known vulnerability. Updates exist. They've existed for over a year. You haven't applied them.
For most apps, this isn't catastrophic immediately. The vulnerability might be relevant only in specific configurations. The exploit might be theoretical. The risk might be low.
But the advisory exists. It's published. A motivated attacker (or even just a curious researcher) can read it. Your app, with its specific outdated dependency, is now on a list. The risk is no longer theoretical for your business — it's a question of when and whether someone notices.
For apps in regulated industries — anything touching healthcare, finance, education — this is more than uncomfortable; it can be a compliance violation. For consumer apps, it's mostly a reputational and platform-relationship risk: Apple and Google have been known to pull apps from the store when persistent security issues remain unaddressed.
Patching a single advisory is not, on its own, a huge project. The problem is that the advisory you just got is rarely alone. There are usually a dozen smaller advisories that have accumulated. Updating one dependency often requires updating several others, which often requires updating the framework version, which requires fixing the API changes, which requires re-testing the entire app.
The work is the work. The longer you wait, the more of it accumulates at once.
Year 3: The App Is Effectively Dead
By year three, the unmaintained app has reached a state where the math gets brutal.
The app crashes on the latest OS versions — sometimes randomly, sometimes consistently. Your reviews are now mostly negative. Your search ranking has collapsed. New users barely find the app, and the ones who do are getting a degraded experience.
The build environment is now multiple major versions out of date. Some of the dependencies your app uses have been removed from the public package repositories entirely. Some of the frameworks have changed their APIs so dramatically that "updating" is less like an upgrade and more like a rewrite.
When the owner finally asks a developer to "just bring the app current", the developer goes quiet for a few days and then comes back with a number that sounds wrong. It isn't. It reflects the reality that the app is no longer something you maintain — it's something you rebuild from.
In the worst cases, the rebuild quote is close to what it would have cost to build a new app from scratch. Sometimes it's higher, because the rebuild has to preserve compatibility with whatever data and users still exist.
This is the decision point that we cover in you think your mobile app needs a rewrite. At year three of unmaintained decay, the rewrite conversation is no longer hypothetical. It's the conversation.
The Math
Here's the part that makes the decay curve worth understanding before you're standing on it.
A reasonable monthly maintenance budget for a typical small-to-medium app is somewhere between $400 and $2,000 per month. The work covered by that budget: framework updates, dependency patches, OS compatibility testing, the occasional small fix, monitoring of the warnings and compliance deadlines, the relationship with the codebase that keeps it inheritable.
Over three years, that's between $14,400 and $72,000 of total maintenance spend. Painful as a line item, but predictable, and the result is an app that's healthy at the end of year three.
The cost of not paying maintenance for three years, and then bringing the app back to a working state, varies. In the best case, it's roughly 2x the avoided maintenance — call it $30,000–$140,000 of catch-up work. In the worst case — when the app has decayed past the point where catch-up is cheaper than a rewrite — it's the cost of rebuilding, plus the cost of migrating users and data, plus the lost revenue from the months your app was on the store with a 3.2-star rating.
The actual cost difference between maintaining and not maintaining is therefore not "the maintenance spend." It's "the maintenance spend, minus a much larger remediation spend at year three." Skipping maintenance isn't saving money. It's deferring a larger payment.
The deferral has emotional appeal — the money you don't spend is real, immediately, and the eventual cost is abstract and far away. The math doesn't care. The math compounds, and the deferral always loses.
Why Owners Underweight This
If the math is this clear, why does it keep happening?
The honest answer is that the costs and benefits don't line up in time.
The monthly maintenance bill is visible. It arrives every month. It's a line in the budget. It feels like spending.
The cost of not maintaining is invisible. It accumulates silently, in increments too small to notice month over month. There's no point in the first year where the owner can clearly see "I have lost this much value by not paying for maintenance." The loss is real, but it doesn't show up in a way that creates urgency.
This is the same dynamic that makes technical debt so easy to accumulate and so painful to address: the cost compounds quietly, and the bill comes due all at once.
Owners who understand this dynamic — even at a non-technical level — make better decisions about maintenance. They treat it less like a discretionary line item and more like something analogous to keeping insurance current, or paying for accounting, or maintaining a physical building. It's not exciting. It's not visible. It is, however, the part of the spend that keeps everything else valuable.
What Healthy Maintenance Actually Looks Like
If you want to avoid the decay curve, the work isn't extensive — it's just consistent.
A healthy maintenance pattern is something like: a few hours of engineering attention every month or two, a quarterly review of warnings and deprecation deadlines, an annual check on the build environment and dependency health, and an actual responsiveness to the platform's compliance dates. The total time is small. The result is an app that stays inheritable, sellable, operable.
This work doesn't need to be done by the original developer. It does need to be done by someone, with the codebase open in front of them, on a schedule. The schedule is the point.
We touch on what this looks like at year one in the first-birthday article and at year two in the year-two tax. The pattern is the same: a structured pause, a structured review, a structured set of decisions. Repeated annually, this is what keeps an app from sliding onto the decay curve.
The Honest Close
There is no version of the mobile app world in which maintenance is optional. There is only the version where you pay it as a monthly expense, and the version where you pay it as a year-three crisis.
The monthly version is smaller, predictable, and produces an app that retains value. The crisis version is larger, surprising, and often produces a forced rebuild — sometimes after months of degraded user experience and lost revenue.
If you're currently paying for maintenance, the right question is whether the work being done is actually keeping the app healthy or just billing time. If you're not currently paying for maintenance, the right question is whether you're in year one (cheapest to recover), year two (still recoverable, more expensive), or year three (the hardest conversation).
Most importantly: the longer you wait to ask the question, the more expensive the answer becomes. The decay curve doesn't reverse. It only gets steeper.
You don't need to know the engineering. You need to know that "we're stable, we don't need maintenance" is a statement about today, and apps don't live in today. They live across years, on platforms that move under them, with users whose phones keep changing. Staying still in that environment isn't staying still. It's falling behind, in a way that compounds.
The buyers who understand this don't make decisions about maintenance based on the next monthly bill. They make decisions based on what they want their app to be worth in year three — and they pay accordingly, in small steady increments, the entire way there.