What Does It Cost to Maintain an App After Launch?
TL;DR
Budget separately for engineering, hosting, tools and support coverage. The two worked examples total £9,792 and £34,008 a year using hypothetical inputs; replace those assumptions with your own workload and rates.
Your app is live. The build invoice is paid. Then a login issue appears on one device, a supplier changes its API and the next release needs testing. None of those jobs adds a feature customers asked for, but someone still has to do them.
An app maintenance budget should separate engineering work, infrastructure, third-party services and support coverage. New features need their own allowance. Combining everything into “ongoing development” makes it difficult to compare quotes or understand why spending has changed.
Below are two worked annual budgets: £9,792 and £34,008, using explicitly chosen assumptions. These are planning examples, not market averages, Pixelfield prices or quotations. Replace the inputs with your own workload and supplier rates before using either total.
What are you actually paying to maintain?
The word “maintenance” can cover several quite different jobs. Agree the boundaries before comparing monthly fees.
| Cost category | What belongs here | What to clarify |
|---|---|---|
| Bug investigation and fixes | Reproducing faults, changing code and checking the fix | Whether a defect is already covered by the build agreement |
| Platform and dependency work | OS compatibility, SDK changes and security updates | Which platforms, versions and dependencies are covered |
| Release testing | Checking important user journeys before shipping | Devices, environments and responsibility for store submissions |
| Infrastructure | Hosting, databases, storage, backups and data transfer | Who pays the provider and what happens when usage grows |
| Monitoring and incident handling | Watching for problems, triage and communication | Coverage hours, response commitments and engineering allowance |
| Third-party services | Messaging, maps, authentication and other paid APIs | Minimum fees, usage charges and account ownership |
A warranty, where your contract provides one, does not necessarily cover a later operating-system change or a third-party integration that stops working. Equally, a fault in the originally agreed functionality should not automatically be billed as a new feature. The applicable agreement determines the boundary; ask for it to be made explicit.
Two example budgets you can change
Both models below use pounds sterling and exclude VAT or other applicable taxes. The rates and allowances are hypothetical inputs chosen for this worksheet on 23 September 2026. They are not a survey of UK agency pricing.
Each assumes a functioning app with usable documentation and deployment access. Neither includes an initial code rescue, a major upgrade backlog, new features, round-the-clock support or payment-processing fees. The engineering allowance includes investigation, routine updates, testing and release work; it is not a promise that every month will fit within it.
Model A: a small app with limited routine work
Imagine a modest app with a straightforward backend and a small number of integrations. Its planning allowance is eight engineering hours a month at an assumed £80 per hour.
| Item | Calculation | Annual allowance |
|---|---|---|
| Engineering | 8 hours × £80 × 12 months | £7,680 |
| Hosting and storage | £60 × 12 months | £720 |
| Monitoring tools | £20 × 12 months | £240 |
| Subtotal | £640 + £60 + £20 per month | £8,640 |
| Unplanned-work reserve | 15% of annual engineering allowance | £1,152 |
| Total planning allowance | Subtotal + reserve | £9,792 |
The recurring subtotal is £720 a month. The reserve is additional money set aside for unplanned work, not a monthly supplier charge. Its 15% value is an editable assumption, not a recommended industry standard.
This model stops being useful if an incident requires a lengthy investigation, an old dependency needs replacing or the app requires guaranteed urgent support. Eight hours is an input to challenge, not a target your developer should be forced to fit.
Model B: an app with more integrations and release work
Now imagine a product with a busier backend, more dependencies and a larger routine testing workload. This example allocates 24 engineering hours a month at an assumed £90 per hour.
| Item | Calculation | Annual allowance |
|---|---|---|
| Engineering | 24 hours × £90 × 12 months | £25,920 |
| Hosting and storage | £250 × 12 months | £3,000 |
| Monitoring tools | £100 × 12 months | £1,200 |
| Subtotal | £2,160 + £250 + £100 per month | £30,120 |
| Unplanned-work reserve | 15% of annual engineering allowance | £3,888 |
| Total planning allowance | Subtotal + reserve | £34,008 |
The recurring subtotal is £2,510 a month. As in Model A, the reserve is a planning buffer. Any separate on-call fee, annual licence, store account fee or additional API bill must be added. Do not assume those costs are included simply because the model has a larger engineering allowance.
Modelled annual allowances: £9,792 and £34,008. Assumptions are shown above; these are not supplier quotations.
You can download the budget inputs and replace the assumptions. The calculation is:
Annual allowance = 12 × (monthly engineering hours × hourly rate + monthly hosting + monthly tools) + reserve + separately identified costs.
Why a percentage of the build price is only a rough check
Two apps can cost the same to build and have very different maintenance needs. One might have an uncomplicated backend and an occasional release. Another might rely on several external services, support older devices and need a quick response when checkout fails.
A fixed percentage does not tell you who will investigate an incident, what happens outside working hours or whether a major platform upgrade fits the agreement. Use a percentage only as a sense check after building a budget from the work and coverage you actually need.
Public prices also need context. Foresight Mobile advertises app support retainers starting at £675 a month, with separate onboarding charges. That is one supplier’s advertised offer, checked on 23 September 2026. It does not establish a UK average, and its included scope is not interchangeable with either model above.
What makes maintenance more expensive?
Changes outside your control
Your app depends on platforms and services you do not own. Google Play has target API requirements for new submissions, updates and availability to new users on newer Android versions. The exact requirements and exceptions change, so check Google’s current target API guidance when planning releases. Updating the target can involve code changes and testing, rather than just changing a setting.
Apple also reviews apps for continued suitability. Its App Store Improvements guidance describes possible removal of certain long-unupdated, minimally downloaded apps and immediate removal of apps that crash on launch. It does not mean every app needs an arbitrary monthly release. It does mean leaving a live app unattended is a business decision with consequences.
The condition of the code and handover
A new maintainer needs a working build, access to the repository and infrastructure, and an explanation of the important integrations. Missing credentials, undocumented releases and unsupported libraries create work before routine maintenance can begin.
Keep that initial assessment and remediation separate from the monthly plan. Otherwise, the first few months can consume the entire allowance fixing problems that existed before the agreement started. Ask for a list of those problems, their priority and how the supplier proposes to handle them.
Coverage and consequences
An internal tool used during office hours has different support needs from an app that takes orders throughout the weekend. A promise to acknowledge a critical incident quickly also differs from a promise to resolve it within that time.
Ask what each response commitment means, which incidents qualify and whether the fee reserves access to an engineer or includes the engineering work itself. A low monthly price is hard to evaluate without those details.
Usage-based infrastructure
More stored media, database activity or messages can increase operating costs even when the app has not changed. Set usage alerts and review the bill against the events that drive it. An AI feature may add model API charges and evaluation work as well; include those explicitly if your app uses one.
Retainer, ad hoc work or your own team?
A retainer can suit a product that needs regular attention and an agreed response arrangement. Check whether unused hours expire, carry forward or are not part of the commercial model at all. Some agreements reserve capacity or cover a defined service rather than selling a bucket of hours.
Ad hoc support can suit infrequent, non-urgent work when someone knows the code and is available. The trade-off is uncertainty: an engineer booked on another project may not be able to respond immediately. Keeping an emergency contact is useful, but it is not the same as purchasing coverage.
An internal team may make sense when maintenance sits beside a substantial roadmap. Account for the actual people and responsibilities: mobile development, backend work, testing, releases and incident handling. One person knowing the system does not remove the need for cover when they are unavailable.
Whichever arrangement you choose, keep the application, infrastructure and store accounts under clear ownership. Being able to move to another supplier is easier when the handover has been considered from the start.
Ask these questions before signing a support agreement
- What is included? Ask the supplier to classify a crash fix, an OS update, a failed integration and a new onboarding screen. The answers reveal the boundary between maintenance and development.
- What happens during a serious incident? Confirm the reporting route, coverage window, acknowledgement target, escalation path and who communicates with your team.
- What costs sit outside the fee? List hosting, paid APIs, store accounts, testing services, out-of-hours work, onboarding and major upgrades.
- How are releases checked? Identify the supported devices, critical user journeys, approval process and rollback or recovery approach.
- What will the monthly report show? Expect completed work, unresolved risks, upcoming platform changes and the costs or allowance consumed.
- How would another team take over? Confirm access to source code, build instructions, credentials management, infrastructure and operational documentation.
These questions make quotes comparable without assuming that the cheapest or largest package is the right one.
What should you track after launch?
Review crashes and failed user journeys alongside support requests, infrastructure bills and the maintenance backlog. Firebase Crashlytics, for example, groups crash reports and highlights affected users and circumstances. A monitoring tool can surface a problem; somebody still needs to investigate it and ship the fix.
Separate the time spent on recurring upkeep from one-off incidents and planned improvements. After several real maintenance cycles, replace worksheet assumptions with the workload you have actually observed. Retain room for known upcoming changes rather than treating a quiet month as proof that the app needs no support.
Planning the initial build as well as ongoing support? Our app development cost guide separates Pixelfield’s published pricing ranges from an illustrative build budget and includes a checklist for comparing quotes.
Bring the app and the scope, not just a target price
To obtain a useful estimate, bring the app’s platform and technology, current hosting and API bills, known issues, release history and the level of support your business needs. Share technical access through an agreed secure process rather than attaching credentials to an enquiry.
Pixelfield provides app launch and ongoing support. If you are still choosing a build partner, our mobile app development service covers the wider delivery process. For costs before launch, see our separate guide to hidden app development costs.
Tell us about the app and the support you need. A useful scope should make clear what keeps the current product working, what improves it and what each part will cost.
