What Does It Cost to Maintain an App?
As a rule of thumb, maintaining an app costs 15–25 percent of the development cost per year. An app that cost SEK 1 million to build therefore needs SEK 150,000–250,000 annually. That covers adapting to new OS versions, updated libraries, bug fixes, and minor improvements – but not new functionality.
The development cost is only the first invoice. An app lives in an environment that keeps changing – new OS versions, updated libraries, tightened store requirements – and needs ongoing care to keep working. Yet maintenance is the line item most often missing from the budget entirely. Here’s what it costs, what’s included, and how to compare maintenance agreements fairly.
The rule of thumb: 15–25 percent of the development cost per year
| Development cost | Typical maintenance per year |
|---|---|
| SEK 500,000 | SEK 75,000–125,000 |
| SEK 1,000,000 | SEK 150,000–250,000 |
| SEK 2,500,000 | SEK 375,000–625,000 |
The logic behind the percentage: the bigger and more complex the app, the more there is to keep in step with the outside world. An app with many integrations and dependencies sits at the upper end of the range; a simple content app at the lower end. Two codebases (native iOS and Android) pull it up, a shared codebase pulls it down.
What maintenance includes
- OS adaptations. Apple and Google preview what’s new in spring and ship the finished versions in fall. Every release can change permissions, APIs, and behaviors the app relies on – it needs to be tested and adapted before users update their phones.
- Library and security updates. Modern apps stand on third-party libraries that get patched continuously. Falling behind is a security problem and makes future updates more expensive with every month that passes.
- Store requirements. The App Store and Google Play regularly raise the minimum requirements for SDK levels and policies. Apps that don’t keep up can be denied updates or, eventually, removed.
- Bug fixing and monitoring. Crash reports, error logs, and performance get tracked, and issues get fixed before they show up in the ratings.
- Minor improvements. Adjusted copy, small UX fixes, a new icon – changes that keep the app feeling fresh without being new features.
Maintenance isn’t further development – draw the line
This is where most contract conflicts arise. Maintenance keeps existing functionality working, secure, and up to date. Further development adds something new: a feature, an integration, a redesign, a new payment solution.
The line matters for two reasons. First, budget: maintenance is a predictable annual cost, while further development is an investment decision that should be planned and prioritized separately. Second, comparability: when one vendor quotes “maintenance” at SEK 10,000 a month and another at SEK 25,000, it’s often the line-drawing that differs – one counts only OS adaptations and critical bugs, the other includes a pool for improvements. Always ask for a list of what’s included, what’s billed separately, and how edge cases are handled.
A worked example
A medium-complexity app built for SEK 1.2 million gives, by the rule of thumb, a maintenance budget of SEK 180,000–300,000 a year. A reasonable setup might be a fixed monthly fee covering monitoring, OS releases, and library updates, plus an hour bank for bugs and minor improvements.
In year one, most of it might go to fall’s OS adaptations and a few bugs – a quiet year, the lower end of the range. In year two, the business wants to add BankID login: that’s further development and gets budgeted as its own small project alongside maintenance. Without that split, the hour bank would have been eaten up and the “cheap” agreement would have turned expensive and conflict-ridden.
How to compare maintenance agreements
Check five things: exactly what’s included (a list, not adjectives), response times per severity level, how unused time is handled, what further development costs when it’s ordered – and that you own the code and accounts so you can switch vendors. A good agreement withstands all five questions without hedging.
Finally, distinguish between reactive and proactive maintenance. Reactive fixes what’s already broken; proactive updates before it breaks. Proactive looks more expensive per month but almost always turns out cheaper per year – technical debt carries loan-shark interest.
At Weapp we maintain the apps we build and also take over existing apps after a technical review – read about our services or get in touch if you want a second opinion on your current agreement.
Frequently asked questions
What happens if we skip maintenance?
The app keeps working – for a while. Then an OS version changes something the app relies on, a library turns up a security hole, or a store requirement demands newer technology. The stores can also remove apps that haven't been updated. Catching up on years of deferred maintenance often costs more than handling it continuously.
Is maintenance more expensive for native apps than cross-platform?
As a rule, yes, since two codebases have to keep up with every OS release, library swap, and security update – double the track, double the work. A shared codebase, in React Native for example, gives both a lower base for the percentage rule and simpler updates.
Should we choose an hour bank or a fixed monthly price?
An hour bank fits when needs vary and you want to pay for actual time; a fixed price gives a predictable budget and a clearer commitment from the vendor. What matters most is that the contract defines what's included, how unused time is handled, and what happens when something urgent comes up.
What's a reasonable response time in a maintenance agreement?
It depends on the app's role. For a business-critical app, hours is reasonable for serious errors, with clear escalation. For a supporting app, the next business day is often enough. Require different levels for different severity grades instead of one general promise – it gets you a better price.
Can another vendor take over the maintenance of our app?
Yes, provided you own the code and it's documented. Request access to the source code, build environments, and system documentation already in the development agreement. An orderly handover takes about a week and is sound insurance against lock-in.