The Bill After Go-Live: Putting UK App Maintenance in the Build Budget
Photo: app maintenance budget spreadsheet team meeting UK office, via lotusarise.com
Launch day has a way of eating the budget. Design, build, testing, store submission, a bit of marketing — and then the invoice arrives for the thing nobody scoped: keeping the app alive. Maintenance is not a rounding error. It is a product cost that starts the day the first user downloads the app.
The tricky part is that maintenance feels invisible during procurement. A statement of work can look complete while leaving out OS updates, store policy changes, security patches and the support rota. Six months later, the team is arguing about whether a broken login on the new iOS release is a 'bug fix' or a 'change request'. Put maintenance in the original build budget and that argument gets a lot shorter.
What actually breaks after launch
Mobile apps are not finished artefacts. They sit on top of operating systems that change every year, stores that revise their rules, and third-party SDKs that update whether you are ready or not. A UK app also has to cope with everything from patchy mobile data on train lines to accessibility expectations and data protection queries.
The predictable work includes OS release testing, store policy compliance, security patching, SLA cover, analytics checks and content updates. None of it is glamorous. All of it is cheaper when planned.
A simple maintenance budget template
For a modest UK app, a sensible starting point is 15–25% of the original build cost per year for ongoing maintenance, depending on integrations, regulated data and how often you ship features. A complex app with payments, health data or multiple back-end systems will sit higher. Use the percentages below as a conversation starter, not a quote.
| Budget line | What it covers | Share of annual maintenance pot |
|---|---|---|
| OS and device regression testing | Testing against new iOS and Android releases, key handsets and accessibility settings | 20–25% |
| Store compliance | Privacy labels, age ratings, screenshots, policy changes and submission admin | 10% |
| Security patching | Dependency updates, certificate renewals, vulnerability fixes and penetration test follow-up | 15% |
| Support and SLA | Triage, response times, incident cover and user-reported bugs | 20% |
| Analytics and crash triage | Monitoring dashboards, crash fixes, funnel checks and reporting | 10% |
| Content and configuration | Copy changes, seasonal content, feature flags and small UX fixes | 10% |
| Contingency | The release that lands badly, the SDK that breaks, the urgent security issue | 10–15% |
That template is deliberately boring. Boring is good when you are trying to avoid a surprise invoice. Add VAT, internal product time and any agency retainer fees on top.
Questions to ask before signing the statement of work
Ask what happens when the next major iOS and Android releases ship. Is regression testing included, or is it a new project? Ask who monitors Apple and Google policy changes and who updates the store listing when the rules shift. Ask what response time you get for a critical bug and whether that changes at weekends. Ask whether security patches are included or treated as extra work.
Then ask the awkward ones. What is explicitly out of scope? Who owns the certificates, keys and store accounts? How do we leave if we want to? What does reporting look like each month? Can we see a twelve-month maintenance plan before we sign, not after go-live? A good partner will have answers. A vague partner will call it 'support' and hope you do not ask for detail.
It also helps to separate maintenance from enhancement. Fixing a broken login after an OS update is maintenance. Adding a loyalty scheme is a feature. Mixing them in one retainer is how budgets get fuzzy and priorities get hijacked by the loudest request.
How to pitch it internally
Do not call it 'ongoing costs' in the business case. Call it what it is: the cost of keeping the product secure, visible and usable. Tie it to risk. A failed store submission delays revenue. A security patch missed is a breach waiting to happen. A crash on a new handset is a one-star review. A support queue with no SLA is a team morale problem.
For UK teams, there is also procurement reality. Public sector buyers, enterprise clients and larger partners often ask for support arrangements, incident processes and evidence of patching. If maintenance is an afterthought, those questions become painful.
The best time to budget for maintenance is before the build starts, when everyone is still talking to each other. Put a line in the budget, agree what sits inside it, and write down what happens when the app breaks at 5pm on a Friday. Your future self will thank you.
