App Maintenance Cost Per Year: Budget in Days, Not Percentages

Guides published in 2026 put the annual cost of maintaining an application at 5% to 25% of what it cost to build. For an app delivered at €30,000, that's €1,500 to €7,500 a year. Application maintenance covers all the work that keeps an app online, secure and accepted by the app stores once it's in production. When two sources are five times apart, you don't have a range. You have a disagreement.

I regularly see quotes where the maintenance line is missing, or shrunk to a percentage tossed in at the bottom of the page. My view: a percentage is a good reflex for getting an order of magnitude, and a poor tool for signing off a budget.

To settle it, we first need to understand why the figures vary so widely, then what maintenance actually covers, then how to convert it into days, and finally what it costs to cut corners here.

What annual maintenance range should you plan for, according to the sources?

The five top-ranking French guides on this topic quote 5% to 25% of the initial development cost per year, and they split into two camps: one around 5% to 8%, the other around 15% to 25%. For an app built for €60,000, that means €3,000 to €30,000 a year. No decision-maker can budget on a range like that.

Why do the percentages vary so much?

Because each author is describing a different scope. According to playmoweb.com (October 2026), the rule is to plan 5% to 8% a year for a mobile app maintained under a prepaid time-credit contract. At the other end, bob-le-developpeur.com (updated 14 October 2026) uses 15% to 20%, or €9,000 to €12,000 a year for a €60,000 app. shortcut-agency.com (August 2026) and eid-lab.com (July 2026) quote 15% to 25%.

The first figure mainly covers bug fixes and mandatory updates. The others add new features on top, which accounts for most of the gap.

The same rate applied to poorly delivered code and well-delivered code won't produce the same bill. That's the limit of thinking in percentages: it treats the build price as a proxy for workload, when the workload actually depends on what changes around the app.

What are you really paying for in annual maintenance?

App maintenance covers four kinds of work: fixing bugs, adapting the app to outside changes, protecting it, and evolving it. Only the last one is a choice. The other three are imposed by third parties: Apple, Google, browser vendors, and the publishers of the software building blocks the app relies on (its dependencies).

Which deadlines force hours of work?

The app stores set the calendar. According to an r/AppFollow thread shared in 2026, r/AppFollow, since 28 April 2026 Apple only accepts apps built with Xcode 26 and the iOS 26 SDK. Since 31 August 2026, Google Play has rejected new apps and updates that don't target Android 16 (API level 36).

Playmoweb notes that Apple released iOS 27 on 14 September 2026, and Google shipped Android 17 on 16 June 2026 on its Pixel phones. An app nobody touches for twelve months falls out of line with these rules, and nobody warns you before the one-star reviews arrive.

Does a mobile app cost more to maintain than a web app?

Yes, because you don't control the calendar and updates have to pass an external review. Apple aims to review 90% of submissions within 48 hours, according to the same r/AppFollow thread, and that delay has to be factored into any recovery-time commitment.

At the extreme end, MobiLoud (2026 video) cites brands that dedicate 2 to 3 people to keeping a native app alive, and up to six in some cases, which is roughly $500,000 a year in salaries. I don't draw a rule from that: it's the top of the range for a large e-commerce player, not the situation of a small or mid-sized business. But it shows that a percentage of the original quote caps nothing.

On the web, the calendar is less tight, but security remains the cost you can't cut. According to eid-lab.com, citing IBM's Cost of a Data Breach 2024 report, a breach costs an average of $4.88 million. Skipping a security update is never a saving.

Why budget in senior developer days rather than a percentage?

Budgeting in days means reserving an annual volume of developer days at an agreed day rate, rather than applying a percentage to the quote. A number of days can be measured, checked and adjusted. A percentage can't.

Full disclosure: I run Extra Dev, which provides AI-augmented senior developers at €180/day, so I'm clearly biased here. Still, the maths is the same with any provider: take their day rate and multiply.

How many days a month should you plan for?

Here's my estimate, not a market standard. For a stable app that isn't getting new features:

• 1.5 days a month (18 days a year, €3,240 at €180/day): monitoring, security updates, a minor fix.
• 3 days a month (36 days a year, €6,480): all of the above, plus one round of adaptation per major iOS or Android release and a few tweaks requested by users.
• 6 days a month (72 days a year, €12,960): an app with many third-party integrations, payments or sensitive data, and regular new features.

These three tiers line up with the bob-le-developpeur.com range: €9,000 to €12,000 a year is 50 to 67 days at €180. The difference is that you can see what you're buying.

A dedicated senior developer with at least 8 years of experience fixes in an hour what someone new to the codebase takes a day to understand. That's why I count in senior days: the same ticket costs less at the right level, even if the day rate looks higher.

If you're weighing hiring against outsourcing this workload, the full calculation is in Recruter un dev senior en CDI ou le prendre en régie à 180€/jour, and the developer cost calculator gives you the figure for your own situation.

What drives app maintenance costs up?

Maintenance costs explode when the code is hard to understand, not when the app is big. Technical debt (the hidden cost of badly written code, which slows down every future change) is the main cause of overruns, and it gets built in during development, not afterwards.

Does the original build really change the annual bill?

Yes, and that's the point percentages ignore. 8090 AI, a developer tools company, claims in a 2026 video that engineering teams spend about 17.3 hours a week maintaining existing code versus 13.5 hours building features, and that maintenance takes up 50% to 80% of their time. They're selling a solution, so I treat those ratios as an order of magnitude, not a neutral finding. The direction, though, matches what I see.

My conviction: an app built properly from the start costs less to keep alive. That means usable error logs, tested backups, an admin back office, tests run in a real browser rather than just generated code, and project documentation the next developer can read in an hour. Code churned out in a few prompts with no framework produces the opposite, as I explain in Vibe coding : la dette technique qui va plomber votre budget.

Do outages cost more than preventive maintenance?

Often. According to Lusig's talk at PlatformCon 2026, 71% of mobile app uninstalls are triggered by a performance problem or a crash. Triaging a major bug takes four hours or more of a senior developer's time, and each interruption costs them about twenty minutes of focus.

I'd point out that Lusig sells mobile observability, but the mechanism is real: a bug found by a user costs more than the same bug caught in a log.

When is it better to rebuild than to keep maintaining?

It's better to rebuild once the annual maintenance cost exceeds roughly a third of the price of a rebuild, because you recoup the savings in three to four years. That's a decision criterion, not a law, and it comes from a costed case published by an industry player.

How do you know maintenance is becoming a trap?

appmobilenormandie.fr gives the example of an app developed in 2019 for €30,000 that now costs €10,000 a year to maintain because of ageing technology. A rebuild would cost €35,000, paid back in three to four years. The same site estimates that initial development accounts for only 20% to 30% of the total cost over the app's lifetime.

I look for three concrete warning signs: every fix breaks something else, nobody can add a feature without a week of analysis, and app store updates now take several days. For the cost of a rebuild, see Refonte d'une application métier : combien ça coûte vraiment en 2026, and for the initial cost, Combien coûte une application en 2026.

A useful framing figure comes from gartner.com: according to eid-lab.com, citing a 2024 Gartner study, companies spend an average of 60% of their total software budget on maintenance. I haven't checked it at the source, so I use it as a trend, not as proof.

How do you check a maintenance contract before signing?

A maintenance contract should be judged on three commitments: the response time, the recovery time, and what the package includes. The r/AppFollow thread found that only 2 of the 10 providers reviewed publish a real service level agreement (SLA, the written commitment on turnaround times).

What should you get in writing?

A response time only promises that someone will acknowledge your ticket. It says nothing about when the app will be working again: ask for a recovery target, and check that coverage extends beyond office hours if your business runs in the evening.

Also ask what happens when the time credits run out, who owns the code and the access credentials, and whether you can scale down or bring the work in-house. A dedicated developer on a time-and-materials basis, with no lock-in, settles most of these points by design. The management routine is covered in Piloter un dev en régie à distance.

My verdict: reserve days, not a percentage

Plan for 18 to 72 senior developer days a year, or €3,240 to €12,960 at €180/day, depending on how much your app changes. The percentage of the quote is there to check you're in the right ballpark, never to sign off on.

What decides between the three tiers?

The deciding factor is how many things change around your app. With no new features and no critical integrations, stick to 1.5 days a month. With OS updates to absorb and active users, plan 3 days. If the app handles payments, sensitive data or monthly feature releases, budget 6 days.

And if the bill exceeds a third of the price of a rebuild, stop maintaining and rebuild. To size your own case, the developer cost calculator gives you the figure in three minutes. For a breakdown of build budgets, read Combien coûte le développement d'une application ?.