An app maintenance contract should say what happens when something breaks.

An app is not finished at launch. It has to keep installing on new OS versions, pass store reviews, survive dependency updates and fix the defects that only appear once real users arrive. A maintenance contract is the agreement about who does that work, how quickly and at what cost.

Most disputes are not about the hourly rate. They are about a sentence that was never written: is a store rejection covered, is a new feature included, who pays for a third-party service, and what happens when the developer leaves. This guide covers the terms that prevent those arguments.

Define the work before the hours

“Maintenance” can mean at least four different things. Treating them as one queue hides the work that actually keeps the product alive.

The contract should state which of those are included, how much capacity is available and how new work enters the queue. If everything is “included”, the important work will compete with every small request and the release will slip.

Response targets are not resolution promises

A response target says when someone will acknowledge and triage an issue. A resolution target says when it will be fixed. The second is much harder to promise, because the cause may be in a third-party SDK, a store review queue or a backend outside the app.

Define severity levels in plain language. For example: a release blocker affects all users or stops a payment; a high-impact defect affects a core flow for some users; a normal defect has a workaround; a low-priority request is an improvement. For each level, state the response window, the expected next update and who can escalate.

Also state the working hours and the holiday policy. “Within four hours” means something different if the developer is asleep. A written window in a named time zone is clearer than an optimistic number.

Write down what is not covered

Good contracts are explicit about exclusions. Common ones include new feature development, design work, content entry, third-party subscription costs, app-store account fees, hardware purchases and work caused by an unauthorised change to the code or infrastructure.

There should also be a rule for emergency work outside normal hours. Is it available, who authorises it and how is it billed? A short paragraph here prevents a late-night argument during a launch.

If the app depends on a vendor SDK, a payment provider or a hosting account, name the owner of that relationship. Maintenance cannot fix an account that the client does not control.

Code, accounts and the exit

Ask for the repository, build instructions, signing setup, environment variables, store console access and a list of third-party services before you need them. A maintenance contract should say that these are yours, or that they will be transferred on exit.

The exit terms matter as much as the monthly price. If the engagement ends, how much notice is required, what documentation is handed over, and what happens to work in progress? A developer who holds the only copy of the release process has more leverage than the contract suggests.

Retainer, block of hours or per-change

A monthly retainer suits a live product with a steady stream of small work. A block of hours suits a product that needs attention periodically. A per-change quote suits a stable app with occasional updates. None of them is universally better; the right model follows the work pattern.

Ask what happens when the retainer is unused. Does it roll over, expire or buy a lower priority? Ask what happens when it is exhausted. A clear overage rule is better than a surprise invoice.

For planning, the site’s pricing guide uses a rough range of 15–25% of the build cost per year for upkeep, not for new product work. Treat that as a planning range, not a quote.

Questions to ask before signing

• ✓
  What exactly is in scope?
  Which work types, how many hours and which releases?
• ✓
  What are the severity levels?
  Response window, next update and escalation path for each.
• ✓
  Who owns the code and accounts?
  Repository, signing, store consoles and third-party services.
• ✓
  What is excluded?
  New features, design, content, subscriptions and emergency work.
• ✓
  How does the queue work?
  Who prioritises, how changes enter and what happens when capacity is full.
• ✓
  What does exit look like?
  Notice period, handover artefacts and work in progress.

If a contract cannot answer these questions, it is not a maintenance plan. It is a monthly payment with an undefined promise. The maintenance service page shows how I structure the work, and the how I work page covers the wider engagement terms.

Arun KumarFreelance App Developer · Kochi, Kerala, India

I build Flutter apps for Android, iOS and Smart TV with Laravel APIs, payments and real-time features, and work directly with clients worldwide. More about my background or get in touch.