App Maintenance Costs After Launch: What to Budget For

Launching an app feels like the finish line.

In reality, it is the start of a commitment that lasts as long as the app is in use. Operating systems update every year, app stores raise their technical requirements, third-party services change their pricing and interfaces, security vulnerabilities appear in libraries you depend on, servers need running and users report bugs and ask for improvements. An app that receives no attention after launch does not stay the same. It gradually breaks, slows down, falls out of compliance and, eventually, may be removed from the stores or stop working on new devices.

A rule of thumb often quoted in the industry is that annual maintenance costs around 15 to 20 percent of the original development cost. That is a reasonable starting point for a first budget, but it is only a rough guide. The real figure depends on how complex the app is, how many integrations and third-party services it relies on, how many users it has, how quickly you want to add features and how well it was built in the first place. Some apps need far less; apps under active development often need much more.

This guide breaks down what app maintenance actually involves, the costs in each area, a worked example of building a budget and practical ways to keep costs under control without letting the app deteriorate. It is written for founders, product owners and business leaders who commission apps, as well as anyone trying to understand why the bill did not stop at launch.

Why apps need ongoing maintenance

It can seem strange that software, which does not wear out physically, needs continuous attention. The reason is that the environment around it keeps changing.

The computer scientist Meir Lehman studied how large software systems evolve and described a set of observations, later known as Lehman's laws of software evolution. Two are especially relevant to apps. The first is that software used in the real world must be continually adapted, or it becomes progressively less useful. The second is that as software changes, its complexity tends to increase unless effort is made to reduce it. Both apply strongly to mobile apps, which run on platforms controlled by Apple and Google, depend on many third-party components and serve users whose expectations shift quickly.

The four types of maintenance

Software engineers commonly group maintenance into four types, a classification reflected in the international standard ISO/IEC 14764. Corrective maintenance fixes bugs and defects discovered after release. Adaptive maintenance keeps the app working as its environment changes, such as new operating system versions, devices, store requirements and third-party service changes. Perfective maintenance improves the app through new features, performance improvements and usability changes based on feedback. Preventive maintenance reduces future problems, for example by updating outdated libraries, refactoring complicated code and improving tests.

Many businesses budget only for corrective maintenance, assuming that once the obvious bugs are fixed, little else is needed. In practice, adaptive work alone is unavoidable every year, and neglecting preventive work makes every later change slower and more expensive.

Platform and app store obligations

Some maintenance is not optional, because Apple and Google set requirements that apps must meet to stay in their stores or to be updated at all.

Annual operating system updates

Apple and Google release major versions of iOS and Android every year, usually with beta versions available months in advance. New versions can change how permissions, notifications, background tasks, privacy settings and user interface components work, and occasionally break existing functionality. Each year, your team needs to test the app against the new versions, fix anything that breaks and take advantage of new requirements, such as changes to how apps request location or photo access. Planning a block of work around the annual release cycle, typically from early summer when betas appear to the autumn launches, avoids last-minute surprises.

Store technical requirements

Both stores raise their minimum technical requirements over time. Google Play requires new apps and app updates to target a recent Android API level, generally within a year of the latest major Android release, and existing apps that fall too far behind can become unavailable to new users on newer devices. Apple periodically requires apps submitted to the App Store to be built with a recent version of its Xcode development tools and software development kit. If your app has not been updated for a while, meeting these requirements can involve more work than expected, because several years of changes may need to be absorbed at once.

The stores also introduce new policy and privacy requirements. Apple, for example, requires App Store privacy details and has introduced privacy manifest requirements for certain commonly used third-party SDKs. Google Play requires a Data safety section and has its own policies on permissions, payments and content. These must be kept accurate as the app changes.

Developer accounts and store fees

The direct costs of staying in the stores are modest but recurring. Apple's Developer Program carries an annual fee, while Google Play charges a one-off registration fee. If you sell digital goods or subscriptions inside the app, store commissions apply; both stores offer reduced rates for smaller developers and for subscriptions after the first year, under programmes such as Apple's App Store Small Business Program. Rules on payments and commissions have been changing in some markets as a result of regulation and court decisions, including the EU Digital Markets Act, so check the current terms that apply to you.

Device and screen changes

New devices bring new screen sizes, aspect ratios, foldable displays and hardware features. Testing on a representative set of current devices, either physically or through device cloud services, is an ongoing cost, especially for Android, where the range of devices is very wide.

Infrastructure and third-party service costs

Most apps are only partly on the phone. Behind them sit servers, databases, file storage, APIs and a collection of third-party services, all of which have running costs.

Hosting and back end

Back-end costs depend on the architecture and the number of users. Apps built on backend-as-a-service platforms such as Firebase or Supabase, or on cloud providers such as AWS, Microsoft Azure and Google Cloud, are usually billed by usage: database reads and writes, storage, bandwidth, serverless function calls and compute time. Costs that are negligible during testing can grow substantially as the user base expands, and unexpected spikes, such as a marketing campaign or an inefficient query, can produce surprisingly large bills.

Budget for hosting at your expected user numbers for the coming year, not your current ones, and set up spending alerts and budgets in your cloud account so that sudden increases are noticed quickly.

Third-party services and SDKs

Modern apps typically rely on several external services: payment processing, push notifications, analytics, crash reporting, authentication, maps, email and SMS delivery, customer support chat, search, video and, increasingly, AI services. Many are free at low volumes and charge as usage grows. Some charge per active user, per message, per transaction or per request.

These services also change. Providers update their SDKs, deprecate old versions, alter APIs, change pricing or, occasionally, shut down. Each change can require development work to keep the app working. For example, Google Play has required apps using its billing system to update to supported versions of the Play Billing Library on a regular schedule.

Domains, certificates and other subscriptions

Smaller recurring costs add up too: domain names, SSL certificates where not automated, email services, design and development tool subscriptions, device testing services and monitoring tools.

Keeping track

Maintain a simple register of every external service the app depends on, including what it does, who owns the account, how it is billed, the current cost, the renewal date and the version in use. This makes it much easier to forecast costs, spot price rises early and plan for changes before they break something.

Bug fixing, monitoring and performance

No app launches without bugs. Some appear only on particular devices, operating system versions or network conditions; others emerge as usage grows or as users find paths through the app that testers did not try. Fixing them, and spotting them early, is a core maintenance cost.

Monitoring

Crash reporting and performance monitoring tools, such as Firebase Crashlytics and Sentry, show which errors users experience, how often and on which devices. Product analytics show where users drop out of key flows. App store reviews and support tickets add qualitative detail. Together they let you prioritise fixes by real impact rather than by who complained most recently.

Platform quality metrics matter commercially too. Google Play's Android vitals tracks user-perceived crash and "app not responding" rates and has published thresholds above which an app may become less visible in the store or show warnings to users on affected devices. Apple's Xcode Organizer reports crashes, hangs and energy use. Monitoring these figures and acting on them protects both user experience and discoverability.

Bug fixing

The cost of bug fixing depends heavily on the quality of the original build. Apps with automated tests, clear code structure and good documentation are much quicker to fix and less likely to break when changed. Apps built hastily, without tests, can turn each fix into a slow investigation with a risk of new problems. Prioritise fixes by severity: crashes and problems in critical flows such as sign-in and payment come first, cosmetic issues last.

Performance

Performance can degrade gradually as features are added, data grows and dependencies change. Slow start-up times, sluggish screens, heavy battery use and large app sizes all lead to poor reviews and uninstalls. Periodic performance reviews, covering start-up time, memory use, network calls, app size and back-end response times, catch problems before users notice them.

Support

If your app has customers, someone needs to handle their questions and problems, route bug reports to developers and keep app store reviews answered. Support may sit with a customer service team rather than developers, but it is still part of the cost of running the app.

Security and compliance upkeep

Security is not a one-off task completed before launch. New vulnerabilities are discovered in libraries, frameworks and services all the time, and attackers actively look for apps and back ends that have not been patched.

Keeping dependencies up to date

Apps and their back ends depend on many open-source libraries and SDKs. When a vulnerability is found in one of them, a fix is usually released, but your app remains exposed until you update and ship a new version. Dependency scanning tools, built into platforms such as GitHub and GitLab and available as separate services, alert you to vulnerable components. Updating regularly, in small steps, is far easier and safer than leaving dependencies untouched for years and then facing a large, risky upgrade.

Reviewing security

Beyond patching, periodic security reviews check authentication, data storage on the device, API security, encryption and access controls. Recognised guidance, such as the OWASP Mobile Application Security Verification Standard, provides a useful checklist. For apps handling sensitive data, payments or health information, an independent penetration test before major releases and at regular intervals is worth budgeting for.

Privacy and regulatory changes

Privacy rules and accessibility requirements continue to evolve. Data protection laws such as the UK GDPR and EU GDPR require that personal data is processed lawfully and securely, and changes to the app or its third-party services may require updates to privacy notices, consent flows and store privacy disclosures. Accessibility requirements, such as those under the European Accessibility Act, which has applied to many consumer services in the EU since June 2025, may require changes to apps that deliver those services. Regulated sectors such as finance and healthcare often have additional obligations. Budgeting a small amount of time each year for compliance reviews avoids expensive emergency changes later.

Certificates and keys

Apps depend on signing certificates, push notification certificates or keys, API keys and similar credentials, some of which expire. An expired certificate can stop notifications or block releases at an inconvenient moment, so track renewal dates as part of routine maintenance.

Improvements and new features

The line between maintenance and new development is blurry, and it is worth deciding in advance how you will treat it in your budget.

Strictly speaking, adding new features is product development rather than maintenance. In practice, almost every successful app needs ongoing improvement after launch. Users request features, analytics reveal confusing flows, competitors introduce new capabilities and business priorities change. An app that only receives fixes and compatibility updates tends to fall behind and lose users, even if it continues to work.

The amount to budget depends on your strategy. An internal tool or a stable utility app may need only occasional enhancements. A consumer app competing for attention, or a product that is central to a business's revenue, usually needs a steady stream of improvements, often delivered through regular releases every few weeks.

A useful approach is to separate the budget into two parts. A baseline maintenance budget covers everything needed to keep the app working, secure and compliant: platform updates, bug fixes, monitoring, dependency updates, infrastructure and store obligations. A product development budget covers new features and significant improvements, which can be scaled up or down depending on results and business priorities. This makes it clear which costs are unavoidable and which are choices.

Use data to direct the product budget. Analytics showing where users drop out, which features are used most and which segments retain best, combined with user feedback and support data, help ensure money goes to improvements that matter rather than to whoever argues most persuasively.

Building a maintenance budget: a worked example

To show how the pieces add up, here is a simplified, hypothetical example. The figures are illustrative, not quotes, and real costs vary widely with location, team rates, app complexity and usage.

A business has launched a cross-platform app for iOS and Android with a cloud back end. It cost $150,000 to build and has around 20,000 monthly active users. Its development partner charges a blended rate of $100 an hour.

Baseline maintenance

Platform and store updates. Testing and updating for the annual iOS and Android releases, meeting new store requirements and testing on new devices might take around 100 hours a year, or $10,000.

Bug fixing and monitoring. Reviewing crash reports and analytics and fixing issues might take around six hours a month, or about $7,200 a year.

Dependency and security updates. Updating libraries and SDKs and applying security fixes might take around four hours a month, about $4,800 a year. Adding a penetration test every other year, averaged at $2,500 a year, brings this area to $7,300.

Infrastructure and third-party services. Hosting, database, storage, push notifications, analytics and other services might cost around $600 a month at this scale, or $7,200 a year.

Store fees and tools. Developer accounts, monitoring tools and other subscriptions might add around $1,500 a year.

That gives a baseline of about $33,200 a year, or roughly 22 percent of the original build cost. That is a little above the commonly quoted 15 to 20 percent, which is typical for apps that depend on a back end and several third-party services.

Product development

On top of the baseline, the business plans a modest programme of improvements: one or two meaningful features each quarter, guided by analytics and feedback. It budgets $30,000 to $60,000 for this, depending on results. Total annual spending is therefore around $63,000 to $93,000.

What changes the numbers

Costs rise with more complex apps, more integrations, separate native codebases for iOS and Android, larger user bases, regulated data, high availability requirements and an ambitious feature roadmap. They fall with simpler apps, cross-platform codebases, fewer third-party dependencies, good automated testing and a stable feature set. Infrastructure costs, in particular, scale with usage, so recalculate them as the user base grows.

Keeping maintenance costs under control

Maintenance costs cannot be eliminated, but they can be kept predictable and reasonable. Many of the most effective decisions are made before launch.

Build with maintenance in mind

The single biggest influence on maintenance cost is the quality of the original build. Automated tests, clear code structure, sensible architecture, documentation and a continuous integration pipeline make every later change faster and safer. Choosing widely used frameworks and libraries makes it easier to find developers and to get support. A cross-platform framework can reduce the amount of code that must be updated twice, although some platform-specific work will always remain. Keeping third-party dependencies to those you genuinely need reduces the number of things that can change underneath you.

Plan around the annual cycle

Much adaptive work follows a predictable calendar. Apple and Google announce new operating system versions and release betas in early summer, launch them in the autumn and set store deadlines that follow. Planning a block of maintenance time around those dates spreads work evenly and avoids rushed fixes.

Update little and often

Small, regular updates to libraries, SDKs and the app itself are cheaper and less risky than occasional large upgrades. Apps left untouched for a year or two often need substantial work just to meet current store requirements, sometimes costing more than several years of steady maintenance would have.

Watch infrastructure costs

Set budgets and alerts in your cloud and service accounts, review usage each month and optimise expensive queries, oversized resources and unused services. Check third-party pricing at expected future volumes before committing to a provider.

Choose the right support arrangement

Maintenance can be handled in several ways. An in-house team gives the most control and knowledge of the app but is a fixed cost and needs a range of skills. A maintenance retainer with your development agency provides a set number of hours or an agreed scope each month, often with defined response times for critical issues, which gives predictable costs and continuity. Ad hoc or time and materials support suits very stable apps with little ongoing change, but can be slower to respond and less predictable in cost. Whatever the model, agree clear service levels for critical problems, such as an app that cannot be opened or a payment flow that fails.

Common mistakes

Spending the whole budget on launch. Leaving nothing for the year after release is one of the most common reasons apps deteriorate. Reserve a maintenance budget before development starts.

Treating maintenance as only bug fixing. Platform updates, store requirements, dependency updates, security work and infrastructure costs arrive every year, whether or not users report bugs.

Leaving the app untouched for long periods. Skipping updates for a year or more often means a large, expensive catch-up when a store deadline or operating system change forces action.

Underestimating infrastructure growth. Usage-based cloud and third-party costs rise with users. Forecast them at expected scale and monitor them monthly.

Not owning your accounts and code. If your developer holds the app store accounts, cloud accounts or code repository in their own name, changing provider or getting urgent help can become difficult. Keep these in your organisation's name, with access granted to the people who need it.

No monitoring. Without crash reporting, analytics and performance monitoring, problems are discovered through bad reviews rather than data, and fixes are slower and more expensive.

Ignoring technical debt. Shortcuts taken to hit a launch date make later changes slower and riskier. Allocate some time each quarter to refactoring and improving tests, so the app stays affordable to change.

Mixing maintenance and features without a plan. When baseline work and new features compete for the same unplanned budget, essential maintenance is often postponed. Separate the two, and protect the baseline.

If you are planning an app or reviewing one that has been live for a while, an experienced mobile development partner can audit its current state, estimate realistic maintenance costs, set up monitoring and update processes, and agree a support arrangement that keeps the app reliable without surprises.