Cost6 min read
App maintenance contracts: what a retainer should cover and how to read the SLA
By Sannan MalikPublished
Short answerA good app maintenance contract lists the work the retainer covers, such as bug fixes, security and library updates, iOS and Android compatibility and store compliance, and says new features are quoted separately. Its SLA defines severity levels with a response time and a resolution target for each, states who pays third-party fees, and sets exit terms that return the code, accounts and documentation to you.
Maintenance means upkeep, not new features
Most disputes about a retainer start with one word. "Maintenance" means different things to the owner and the developer.
To the owner it often means anything the app needs after launch. To the developer it usually means keeping the existing app working: fixing defects in what was built, applying security patches to libraries, keeping the app compatible with new phone operating systems and meeting store rules. A new screen, a new payment method or a redesigned flow is new work, even when it is small.
I would want the contract to draw that line in writing, with two or three examples on each side. Then decide what happens to requests that fall on the feature side. Some retainers include a fixed number of hours that can go towards small changes; others quote every change separately. Both are fair. A contract that says neither is the problem, because every request then becomes a negotiation.
Response time and resolution time are two different promises
Read the SLA numbers twice. Many only promise a reply.
Response time is how quickly someone acknowledges the problem and starts looking. Resolution time is how quickly the app works again, either fixed or with a workaround. A contract that promises a one-hour response but says nothing about resolution has promised an email. Look for both, and check whether the clock runs in business hours or around the clock, and in which time zone. If your customers are in the UAE and your developer works in another country, the working week and public holidays may not line up, so the contract should say whose calendar applies.
Severity levels decide which clock applies. A sensible scale has three or four levels, defined by what the user experiences rather than by how hard the fix is.
- Critical: the app or backend is down, nobody can log in, or payments fail for everyone.
- High: a main flow is broken for some users, with no workaround.
- Medium: a feature misbehaves but there is a workaround.
- Low: cosmetic issues, wording, minor layout problems.
Yearly store and OS update work
This is the clause people forget. It costs real hours.
Both stores raise their technical minimums over time, and an app that falls behind cannot ship updates. Apple's upcoming requirements page says that since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK. Google Play's target API page says that since August 31, 2026, new apps and app updates must target Android 16 (API level 36) or higher, and existing apps must target Android 15 (API level 35) or higher to stay available to new users.
Moving an app to a new SDK or target level can be a quick rebuild or a week of fixing libraries that changed. So the contract should say whether the yearly upgrade is inside the retainer, capped at a number of hours, or quoted when it comes up. I would also ask the developer to tell you in advance when a store deadline is approaching, rather than finding out when an urgent fix is rejected at upload.
A clause-by-clause checklist for the contract
Put the proposal next to this table and mark each row. A row with no matching clause is a question to send back before you sign.
| Clause | What a clear version says | Warning sign |
|---|---|---|
| Scope of maintenance | Lists covered work: defect fixes, security patches, OS and store compatibility, monitoring | "General support" with no list |
| New features | Quoted separately, or drawn from a stated number of included hours | Silent, so every change is argued |
| Severity levels | Three or four levels defined by user impact, with examples | Severity decided by the developer alone |
| Response and resolution | Both times stated for each level, with business hours and time zone | Only a response time |
| Store and SDK upgrades | Included, capped or quoted, with advance warning of deadlines | Not mentioned |
| Backend and server | Who patches the server, watches backups and renews certificates | Assumed to be the hosting company |
| Third-party fees | Paid by you from accounts in your name | Billed through the developer with a markup and no visibility |
| Reporting | A monthly note of what was fixed, updated and still open | No record of hours or work done |
| Term and price changes | Length of term, notice to change the fee | Automatic renewal at a new price |
| Exit | Notice period, handover of code, accounts and documentation, removal of developer access | Code or accounts held until a fee is paid |
Who pays third-party fees, and how you leave
Your app runs on other people's services: store accounts, hosting, the database, email, SMS, maps, push and payments. Each sends its own bill. I recommend those accounts sit in your company's name and are paid from your card, so the retainer pays for work, not for pass-through costs you cannot see. My post on running costs after launch lists the usual ones.
Exit terms matter most on the day you need them. A good contract lets either side end the retainer with a stated notice period, and says what you receive when it ends: the latest code in your repository, any keys or credentials the developer holds, and notes on how to build and release. If the code and accounts were in your name from the start, as my app handover checklist recommends, leaving is mostly a matter of removing access. I am not a lawyer and this is not legal advice; have the termination and ownership clauses read by one before you sign.
Where my packages stop and maintenance starts
My app packages are fixed prices for the build: Launch at $999 for up to 10 screens, Growth at $1,699 for up to 25 screens with a Node.js backend and PostgreSQL database, and Scale at $2,500 for up to 50 screens with an admin dashboard. Ongoing maintenance is not included in any of them, and neither are hosting or third-party fees.
The package you choose shapes what a maintenance contract has to cover. A Launch app that connects to APIs you already run mostly needs the yearly store and OS work. Growth adds a server and database to patch and back up. Scale adds integrations and push notifications, each of which can change under you. Tell me what you expect after launch and I will list it in the written scope, so the maintenance conversation starts from a clear picture of what was built.
Questions
- Is a monthly retainer better than paying per update?
- A retainer suits an app with a backend, real users and regular small changes, because someone is watching it. Paying per update can suit a simple app that rarely changes, as long as you budget for the yearly store and OS upgrade.
- What resolution time should I ask for on a critical issue?
- There is no standard number. Ask for a resolution target, not just a response time, and make sure it matches how much an outage costs you. A booking or ordering app needs a tighter promise than an internal tool.
- Does maintenance include updating the app for new iOS and Android versions?
- It should say so either way. Keeping up with Apple's SDK minimums and Google Play's target API level is upkeep, but some contracts quote it separately. Check the clause before you sign.
Sources
Platform rules and fees in this article were checked against these official pages on 9 November 2026. They change, so confirm before you rely on them.
Sannan Malik is a software architect and product builder with 8+ years in software, CEO of Alpha Notic FZC and a Certified Scrum Product Owner. He builds mobile apps and business software for companies in the UAE, UK and US.
