What an app maintenance agreement should cover

Most app owners sign a maintenance agreement only to discover, months in, that critical issues fall outside what they thought they'd paid for. A vague contract that lists "updates and bug fixes" without specifying response times, what counts as a bug versus a feature request, or who owns the code leaves you vulnerable when something breaks during peak trading hours.

The best way to avoid this is to know exactly what a solid maintenance agreement should spell out before you even talk to a developer. This isn't about getting bogged down in legalese—it's about being clear on who does what, when, and what you're paying for.

Core support and incident response

Your agreement should define how quickly the developer will acknowledge a problem and how long they'll take to fix it. The difference between "we'll look at it within 48 hours" and "we'll provide a fix within 48 hours" is massive. One means they might only start investigating after two days; the other is a hard deadline for resolution.

Ask the developer to separate issues into categories—critical (app won't load, payment processing broken, data loss), high (major feature unusable), medium (cosmetic bugs, minor functionality gaps), and low (enhancements or polish). Each category needs a clear response window. Critical should be same-day or next-morning; others might stretch longer. Document what constitutes each level so there's no argument later.

Also clarify what's included: Does the agreement cover your users reporting bugs, or only issues you spot? If a customer's device runs iOS 18 and the app crashes, is that covered? It should be, because OS updates are inevitable and keeping the app compatible is core maintenance work.

Scope of work and what's excluded

This is where the real friction happens. "Maintenance" can mean anything from "keeping the lights on" to "we'll rebuild half the app." Your agreement needs to say what the developer will and won't do each month or billing cycle.

Include these boundaries:

• Security patches and critical OS compatibility updates are in. New features are out.
• Minor UI tweaks (button colour, text change) are in. Full redesigns are out.
• Fixing bugs in the original code are in. Rewriting poorly structured code on demand is out.
• Monitoring app performance and alerting you to issues is in or out (specify which).
• Updates to third-party libraries and dependencies are in, but at what frequency?

If the developer didn't build the original app, ask them to state upfront what they *won't* maintain—legacy code they can't safely touch, proprietary integrations they don't have credentials for, or very old technology stacks. An honest developer will name these limits in writing.

Update frequency and testing

The agreement should say how often the developer will push updates and whether they test on real devices before release. "As needed" sounds flexible but becomes a nightmare if critical OS updates arrive and the developer sits on them for a month.

Ask for clarity on:

• How many hours of testing will happen before an update goes live?
• Will it be tested on at least the two most recent OS versions?
• Who bears the cost if an update breaks something—the developer or you?
• How will the developer keep you informed of planned maintenance windows?
• If something does break post-update, how quickly will they roll back or fix it?

Also state whether ongoing monitoring is included. Some developers will alert you the moment crash reports spike or performance degrades. Others hand you log access and leave you to spot problems yourself. Know which one you're getting.

Payment and escalation

Fix the price structure: is it a monthly retainer, hourly, or per-incident? If it's a retainer, what happens to unused hours—do they roll over or vanish? If it's hourly, what's the minimum billing increment, and does the developer track time transparently?

Lastly, build in an escalation path. If a bug fix is taking longer than expected, who do you call? Will the developer bring in another pair of eyes, or do you just wait? A good agreement names a point of contact and sets expectations for when extra resources get deployed.

When you're ready to lock in an agreement, use these specifics as your checklist during negotiation. A developer who can't pin down these details in writing isn't ready for a proper maintenance relationship. On Strove you can request quotes from verified app maintenance providers who can walk you through exactly what their agreements include—get a few versions and compare the terms, not just the price.