Questions to ask before an app maintenance agreement

Most people sign app maintenance agreements after a single conversation, then discover six months later that "maintenance" meant something different to both parties. The questions you ask now—and how you listen to the answers—determine whether you'll have a reliable partner or a mounting frustration.

Is your coverage reactive, proactive, or both?

This separates a true maintenance partner from a break-fix service. Ask: "If my app crashes at 2 a.m. on a Sunday, what happens?" A good answer includes a response window (often 24 hours for critical issues), an escalation path, and someone's contact method. Then ask the inverse: "Do you monitor the app continuously, or only when I report a problem?" Proactive monitoring catches issues—slow databases, memory leaks, API changes from third parties—before users notice them. An evasive answer here is "We fix things when you call," which leaves you paying emergency rates for preventable outages. A clear answer separates your annual cost into a base retainer (proactive work) and incident response rates (things that go wrong unexpectedly).

What happens when Apple or Google push a major OS update?

Operating system updates break apps regularly. Your app might stop working, or be pulled from the store without warning. Ask: "Who tests my app against new OS versions, and when?" The answer should name specific people and mention a timeline—ideally, testing starts before a major release goes live, not after your users report crashes. Follow up: "If changes are needed, who codes them, and what's the turnaround?" A vague answer like "We'll handle it" leaves you guessing whether that means three days or three months. A concrete answer sounds like "Our QA team tests on beta versions, and critical fixes go live within a week of release." This matters because app stores penalise outdated apps by reducing visibility, and users delete apps that don't work.

Who owns the codebase, and what access do I have?

Ask for a written commitment: your source code, any documentation, and all login credentials (Apple Developer account, Google Play Console, cloud hosting, analytics tools) stay in your control or are handed over on request. A reluctant answer—"We'll keep it secure"—is a red flag. You want to hear "Your code is yours; we'll provide it on request" or, better, "You have access to everything at all times." Then ask: "If I leave you tomorrow, can I switch to another developer without rebuilding the app?" If the answer is qualified ("It depends on the code quality" or "Maybe, but it'll take time"), that developer has made your app unnecessarily complex or platform-locked. A maintainer confident in their work says yes.

What's included, what costs extra, and how do you measure it?

The agreement should list concrete deliverables: bug fixes, security updates, monitoring, performance reports, or store compliance checks. Anything vague—"ongoing support"—will become a negotiation. Ask: "If I need a small feature tweak or a new API integration, is that maintenance or a separate project?" The answer tells you where the boundary sits. Then ask: "How do you charge for things outside the agreement?" Expect hourly rates or fixed quotes, but not retroactive surprises. Finally, ask: "What metrics do you track monthly?" A serious maintainer provides monthly reports showing app performance, crash rates, update timelines, and issues resolved. This isn't about policing; it's about visibility. If they're unwilling to report, they have no incentive to keep things tidy.

Bring these four questions to every conversation, take notes on the answers, and compare them across developers. The ones who answer directly—even if their terms aren't perfect—are usually more reliable than those who promise everything and explain nothing. A good maintenance agreement is boring to read and smooth to live with. Find the developer on Strove who can explain their process clearly, and you've already solved half the problem.