How much does it cost to maintain an app per year?

There is no single number, because "maintenance" covers four different costs: cloud infrastructure that grows with usage, third-party subscriptions, a maintenance agreement with a defined scope, and new development. The first three can be calculated from a list — last year's bills, the subscription list and a quote for the agreement against a written scope. What most affects the agreement itself: the service window, the number of platforms, the number of integrations and the state of the code.

What is the difference between response time and resolution time?

Response time is until a person confirms receipt and starts working. Diagnosis time is until the cause and the plan are known. Resolution time is until the system works again — even via a temporary workaround. A proposal that states only response time says nothing about when the incident will be fixed, so insist that all three clocks are written down for every severity tier.

Are new features included in maintenance?

Usually not, and that is a good thing. Maintenance keeps what exists working, secure and current; new development changes the product. When they share a budget, the urgent feature always beats the security update. A good agreement defines the line — for example: a copy or settings fix is maintenance, a new screen is development — and the way to order work beyond it.

Who should own the cloud and store accounts — us or the vendor?

You. The accounts in your name, the invoices to you, and the vendor gets access — not ownership. That separates the cost of services from the cost of labor, and if you change vendors the system does not depend on the cooperation of whoever is leaving. If the accounts are in the vendor's name today, transferring them is the first thing to sort out — before any conversation about switching.

Can maintenance be done without a fixed agreement — only when there is a problem?

You can, but then there is no monitoring, no ongoing security updates, and nobody committed to handling times. That suits a small internal product you can live without for a few days. For an app customers pay through, it means the first incident will be discovered by a customer, and the queue for handling it will depend on the vendor's availability that week.

What should a maintenance report contain?

Four parts on one page: which versions and components were updated and what was deferred; every incident with its severity tier and the three actual clocks against the agreement; what work was done within the agreement and what was ordered separately; and risks and recommendations — components approaching end of life, a growing cloud bill, a recurring problem. Without the second part the SLA is a promise that cannot be checked.

GUIDE · MAINTENANCE · BUDGET

What does app maintenance include, and how do you budget for it?

Launch is not the end of the spend — it is the start of a different one. This guide breaks it into four types and explains what exactly a maintenance agreement buys.

Onezero LabsOctober 22, 2026Updated October 24, 202610 min read

The short answer

App maintenance is one of four recurring costs after launch — alongside infrastructure (servers, storage, cloud services), third-party vendors (app stores, email and SMS services, maps, payments) and new development. A good maintenance agreement states explicitly what is included: monitoring, security and version updates for libraries and operating systems, adapting to new store requirements, incident handling and backups — and what is not: new features, design changes, and the vendors' own costs. The SLA inside the agreement sets a service window, severity tiers, and for each tier three separate clocks — response, diagnosis and resolution — whose values are fixed in the agreement, not in a promise. The budget is built from that list: fixed costs known in advance, plus a reserve for incidents and unplanned change.

The short version — four costs, and who owns each
Expense type	What it is	Who gets paid	How to budget it
Infrastructure	Servers, databases, storage, network, monitoring	The cloud provider — directly, from an account in your name	Usage-based; grows with users and data. Review the bill monthly
Third-party vendors	App stores, email/SMS, maps, payments, analytics, AI services	Each vendor separately — again from your accounts	Fixed + usage-based; one list of every subscription with its renewal date
Maintenance	Monitoring, updates, security, incidents, backups, store compliance	The team or vendor that maintains — per agreement	Fixed by service scope; the scope is written in the agreement
New development	Features, design changes, new screens, new integrations	The same team or another — but under a separate order	From the product roadmap; not out of the maintenance budget

"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 summarizes 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 labor, 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 what the initial development estimate is made of in a separate guide. This one is about what comes after it.

What a development estimate is made of — the initial 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.

An example of a common split. In a real agreement every row has to be written explicitly — including the ones in the 'usually excluded' column.
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 authorized 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-behavior 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:

The right-hand column is what the agreement has to set — per severity tier. The guide does not propose values.
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.

An example structure. Frequency — monthly or quarterly — is set in the agreement.
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

FAQ

Frequently asked questions

Let's talk

Got a project to scope?

One conversation. You leave knowing what the first version needs to contain and what it will take to build it.

Straight. To the point. On time.