Mobile app maintenance contract — SLA, scope and what to put in writing before you need it

A mobile app maintenance contract is usually drawn up in a hurry: the app is already in the stores, the build project has wrapped up, and someone has to keep an eye on updates and fix bugs. The parties sign two pages about “ongoing support”, and nobody looks at the document for the first year.

People look at it at three moments: when the app stops working on a Friday evening, when an invoice arrives that is bigger than usual, and when you want to change vendors. This article describes what the contract should contain so that it has an answer at each of those moments — from the perspective of a software house that signs these contracts in two roles: as a new vendor, and as the team a client hands a project over to after someone else.

This is not legal advice. Talk to a lawyer about copyright and personal data — here we describe what the contract should contain from a technical and operational point of view.

Scope: what “maintenance” means

The most common dispute over app maintenance is not about the rate, but about whether a given piece of work falls under it at all. That is why it pays to write the scope out explicitly, in three groups:

Maintenance (what has to be done to keep the app working):

• annual adjustments to store requirements — raising targetSdk for Google Play and building the app with the required Xcode version for the App Store;
• updating libraries and the framework, including security patches;
• fixing bugs reported by users and detected by crash monitoring;
• responding to app rejections by the stores;
• preparing and publishing releases.

Development (new things): new features, design changes, integrations. Usually billed from the same pool of hours, but estimated and approved separately.

Out of scope: things the vendor does not control — outages of third-party services, changes on a backend it does not maintain, in-app content. If someone else maintains the backend, say so explicitly and agree who coordinates a ticket when it is not clear which side the bug is on.

A good test is the question: is the annual update for the new Android and iOS included in the maintenance price, or is it a separate project? If the contract does not give a clear answer, you will be having that conversation in a year. We cover what makes up this cost in how much mobile app maintenance costs.

Billing model

Three models are the most common:

Whatever the model, put the following in the contract:

• what happens to unused hours — they expire, roll over to the next month (and for how many months), or the vendor keeps them as a buffer for urgent tickets;
• the rate for hours beyond the package and whether they require prior approval;
• how the volume changes — how much notice you need to give to increase or decrease it;
• reporting — a monthly list of tasks with hours. Without it you cannot tell whether the package is the right size.

SLA: response time is not fix time

Most misunderstandings come from confusing three different times:

• response time — from the ticket being raised to confirmation that someone is on it and knows its priority;
• workaround time — until the problem stops blocking users, even if it is not fixed yet;
• fix time — until the actual fix is deployed.

An SLA that promises a “fix within 4 hours” is usually impossible to meet for a mobile app, for a reason the vendor has no control over: store review. A fix can be ready in an hour, but it reaches users only after Apple or Google approves it and after users update the app. That is why the contract should measure the time to submitting the fixed version to the store, not to it appearing on phones.

A typical priority breakdown:

Support outside business hours and at weekends is a separate service — on-call costs money, because someone has to be by the phone. Consider whether you need it. For many business apps a quick response on business days is enough.

How to shorten fix time without a release

The best way to get a short workaround time is an architecture that lets you react without a new version in the store. It is worth writing into the contract (or into the work plan for the first month) that the app has:

• remote configuration and feature flags — the ability to switch off a problematic feature from the server;
• a forced update mechanism — a message for users on a version that is too old;
• crash monitoring with alerts, so you learn about a problem before your users do.

Gradual rollouts help too (staged rollout in Google Play, phased release in the App Store) — a bug that slips past testing reaches only a small share of users first. We describe how to set this up in the article on mobile app crash monitoring.

Ownership and access

This is the part of the contract that does not matter for years, and then decides everything.

• Store accounts, the repository, Firebase, cloud and the domain belong to the client. The vendor gets access with an appropriate role, but is not the owner. It is one clause that saves weeks when you change vendors — as the article on what to do when your developer disappears shows.
• Copyright in changes. Under Polish law, a transfer of economic copyright must be made in writing or it is void, and it covers only the fields of exploitation expressly listed in the contract. Agree that the rights to code written as part of maintenance pass to the client — ideally on payment for the given period — and list the fields of exploitation, including the right to have the code modified by other vendors.
• Code kept in the client’s repository at all times — not a “handover at the end”, but work directly in a repository that belongs to you.
• Keys and secrets — stored somewhere the client has access to (a password manager, a CI vault), not on a developer’s laptop.

Personal data and security

If the vendor has access to the production database, logs or crash reports containing user data, you need a data processing agreement (art. 28 GDPR). It defines which data the vendor can access and for what purpose, how it protects that data, and what it does with it once the engagement ends.

In the same section it is worth setting out:

• who at the vendor has access to production environments (by name or by role);
• an obligation to report a security incident within a defined time;
• whether the vendor may use subcontractors, and on what terms;
• how AI tools are handled — whether the client’s code may be sent to external services.

Ending the engagement

Every maintenance contract ends at some point, and it is worth agreeing how it ends at the start, while both sides still like each other.

• Notice period — usually one to three months. A shorter one gives flexibility, a longer one gives time for a smooth handover.
• Handover obligations — up-to-date code in the repository, build and release documentation, a list of access rights to revoke, knowledge transfer.
• Handover hours — a set number of consulting hours for the new vendor after the contract ends, paid at the contract rate.
• Revoking access — with a date after which the vendor no longer has access to any resource.

If this sounds like a list for a break-up on bad terms — yes, that is exactly what it is for. We describe it in detail in the project handover checklist.

Red flags in a mobile app maintenance contract

• Store and repository accounts set up in the vendor’s name “for convenience”.
• No transfer of copyright, or a transfer without the fields of exploitation listed.
• An SLA measured to “resolving the problem”, with no definition of what that means.
• A fixed fee without a list of the work it covers.
• No hours report.
• No provisions on ending the engagement and handing the project over.

Summary

A good mobile app maintenance contract answers four questions: what is included in the price, how quickly someone will respond (and what “respond” means), who owns the app, and how to part ways. The answers to the first two decide whether the collaboration is comfortable. The answers to the last two decide whether changing vendors costs you a week or three months.

In mobile app maintenance we work with a number of hours set by the client, on the client’s accounts and in the client’s repository, with a monthly work report. If we take over a project from someone else, we start with a free app analysis — after it, it is clear what level of maintenance is needed, and whether any is needed at all.