"How much does it cost to maintain an app" usually gets a percentage as an answer — a share of the development cost, every year. That percentage does not help anyone who has to plan a budget, because it mixes four different costs with four different mechanisms: one grows with usage, one is a list of subscriptions, one is a service with a defined scope, and one is a product decision. This guide separates them, then goes deep on the third — maintenance: what it includes, what it does not, and how to read the agreement.
The four expense types after launch
The table above summarises them. Three things in it matter before going further:
- Infrastructure and vendors are paid from your accounts — not through the maintaining vendor. Even when our team sets up and manages the cloud account, the account is in your name and the provider's invoice reaches you. This separates the cost of services from the cost of labour, and ensures that changing maintenance vendors does not disconnect your server.
- Maintenance and new development are two budgets. When they mix, maintenance gets eaten by this month's urgent feature and the security update slips. A good maintenance agreement says explicitly where the line is, and how work beyond it is ordered.
- Only one of the four — maintenance — is a fixed price that can be set in advance. The rest need tracking: the cloud bill grows, a forgotten subscription renews, and new development is a decision every quarter.
If you are still before launch, we broke down the initial spend — development itself — in a separate guide. This one is about what comes after it. How much it costs to build an app — the initial development budget
What a maintenance service includes — and what it does not
"Maintenance" is a word every vendor fills differently. The only way to know what you are buying is an included / excluded table. The table below is an example of a common split — not any vendor's terms of service, and not ours either. Use it as a list of questions against the agreement in front of you.
| Area | Usually included | Usually excluded — separate |
|---|---|---|
| Monitoring | Uptime, errors, performance; alerting whoever handles it when something deviates | Setting up monitoring from scratch for a system that had none; business dashboards |
| Updates | Security and version updates for libraries, frameworks and operating systems; verifying everything works afterwards | A major version migration that requires rewriting (e.g. a framework at end of life) — a project in its own right |
| App stores | Adapting to new Apple and Google requirements, certificate renewal, resubmitting an existing version | The stores' own developer fees; compliance that requires a new feature |
| Incidents | Diagnosing and fixing bugs in the existing code, by the severity tiers in the agreement | Incidents originating with a third party (e.g. a payment service outage) — handled with them, not fixed on our side |
| Backups and restore | Scheduled backups, periodic restore tests, an actual restore when needed | Recovering data deleted by an authorised user; changing retention policy due to new regulation |
| Development | Small fixes to copy, settings and configuration | New features, new screens, design changes, new integrations |
| Reporting | A periodic maintenance report (see below) | Product advice, roadmap planning, user-behaviour analysis |
Two rows in the table generate most disputes: "incidents" — because someone has to decide the severity tier — and "development" — because the line between a small fix and a feature is always a question. A good agreement solves both the same way: a written criterion, and a named decider when in doubt.
How an SLA is defined — without the numbers
An SLA (Service Level Agreement) is the part of the agreement that says what happens when something breaks. It has three parts, and all of them need to be written down — but the values inside them belong in the agreement, not in a guide.
1. The service window
When the team is available to act: working days and hours, what happens on holidays, and whether there is an emergency path outside the window — and at what cost. An app that serves customers at weekends needs a different service window from an internal system, and this is one of the things that most affects the price of the agreement.
2. Severity tiers
Not every incident is equal. Most agreements define three or four tiers by business impact — not by technical difficulty. A common split:
- Critical — the system is down, or a core flow (payment, sign-up, ordering) fails for all users.
- High — a core flow fails for some users, or a workaround exists but is not reasonable for long.
- Medium — a secondary feature fails; the business continues.
- Low — a cosmetic issue, a copy error, a small improvement request.
The question that has to be written down: who assigns the tier in real time, and what happens if client and vendor disagree.
3. Three clocks — not one
"Response time" is the number that appears in every proposal, and it is the least important one. Each severity tier has three different clocks, and each should be defined separately:
| Clock | What it measures | What the agreement needs to state |
|---|---|---|
| Response | How long until a person confirms receipt and starts working | A value per tier, inside and outside the service window |
| Diagnosis | How long until the cause and the action plan are known — a fix, a workaround, or escalation to a third party | A value per tier, and how the client is kept informed meanwhile |
| Resolution | How long until the system works again — even via a workaround — and when the permanent fix lands | A target per tier; what counts as 'resolved'; what happens when the cause is with a third party |
A sample maintenance report — what should be in it
A periodic maintenance report is the only way to know that the service you pay for is happening. The structure below is a generic example — not a client's report. A real one is shorter than it sounds: one page, four parts.
| Section | What it contains | Why it is there |
|---|---|---|
| Versions and updates | Which libraries, frameworks and infrastructure components were updated, from which version to which, and what was deferred and why | So you know the system is not quietly accumulating security debt |
| Incidents | Every ticket: date, severity tier, the three actual clocks against the agreement, the cause, what was fixed | So the SLA is verifiable — not just promised |
| Work performed | What was done within the agreement and what was ordered separately; if the agreement is hours-based — how many were used and how many remain | So the line between maintenance and development stays visible |
| Risks and recommendations | Components approaching end of life, a growing cloud bill, a subscription about to renew, a recurring problem | So the next decisions — budget, upgrade, replacement — are made in advance, not under pressure |
How to build the annual maintenance budget
Not from a percentage. From a list. The order of work:
- Collect the fixed costs: the maintenance agreement, every third-party subscription with its renewal date, the stores' developer fees. These are known in advance.
- Add the variable costs from last year — mainly the cloud bill — with the growth you expect in users and data.
- Keep a reserve for the unplanned: an incident beyond the agreement, a new store requirement that needs development, a library reaching end of life. Its size is your decision — but zero is not an answer.
- New development — on a separate line, from the product plan. If there is no plan, this line is what will eat everything else.
What most affects the maintenance line itself: the service window (working hours only versus round the clock), the number of platforms (iOS, Android, web, server), how many external integrations can break, and the state of the code — a system with automated tests and documentation is cheaper to maintain than one without, and that is a consideration worth bringing into the development phase.
What to check before switching maintenance vendors
Sometimes the reason to read a guide like this is that the current vendor is not delivering. Before switching, four checks that save most surprises:
- Ownership — the code repository, cloud accounts, domain, store accounts and third-party vendor accounts: whose name are they registered in today? Anything not in your name needs to move before the current vendor knows they are being replaced.
- Access — who holds passwords, keys and signing certificates. Losing the Android app's signing certificate, for example, is a hard problem to fix.
- Documentation — how to run the system from scratch, how to deploy a version, what each environment's configuration is. If it is not written down, the new vendor will pay to discover it — and you will pay them.
- Overlap — whether the current agreement allows a transition period in which both vendors are available, and what it costs.
The full list — including what to ask the outgoing vendor for and in what order — is in our takeover checklist. Software project takeover checklist — moving from a previous vendor
What we do at this stage
Before a maintenance agreement we do a short mapping of the product, its usage and responsibilities: which platforms and services exist, what is monitored today and what is not, who holds each account, and which service window the business actually needs. From that the scope is written — what is included, what is not, and the severity tiers — and only then a price. If the system comes from a previous vendor, this mapping is also the takeover step. Taking over and maintaining an existing product — what the service includes