What Does a Mobile App Actually Cost to Maintain After Launch?
Ongoing maintenance for a business mobile app typically runs 15–25% of the original build cost per year, and that figure surprises most first-time app owners because almost every conversation before launch is about the build price, not what happens the day after it ships. A web development company in Pune quoting ₹4–8 lakh for a straightforward business app is quoting the easy, one-time number. The recurring number — OS updates, app store compliance, bug fixes, server costs, and the eventual "this needs a rebuild" conversation — is the one that determines whether the app is still worth having three years in.
This matters more for mobile apps than for websites because of a structural difference: nobody else controls when your website needs to change, but Apple and Google absolutely control when your app needs to change, on their timeline, not yours. A website you leave untouched for a year is usually still working. An app you leave untouched for a year risks being pulled from the store, rejected on the next mandatory update, or simply broken on the newest phones.
Why Apps Cost More to Maintain Than Websites
Forced platform updates. Apple and Google each ship a major OS version roughly annually, and both platforms periodically raise the minimum SDK version an app must target to remain installable or to pass store review for updates — Google Play, for instance, requires apps to target a recent Android API level on a rolling basis, and apps that fall behind stop being distributable to new installs even if existing installs still work. This isn't optional maintenance; it's a deadline set by a platform you don't control, and missing it can mean your app quietly disappears from search results or new installs even though nothing about your business changed.
App store policy churn. Both stores update their review guidelines multiple times a year — privacy disclosure requirements, permission justification rules, changes to how in-app purchases or external links must be presented. An app that passed review two years ago can fail review on its next routine update if a policy changed in between, which means even a trivial bug fix release can turn into a multi-day back-and-forth with app review if nobody's been tracking the policy changes.
Device fragmentation, especially on Android. iOS has a comparatively small number of device and screen-size combinations to test against. Android spans hundreds of manufacturers, screen sizes, and OS customizations (Samsung's One UI, Xiaomi's MIUI, and others all modify stock Android behaviour in ways that occasionally break things stock Android wouldn't). A feature that works perfectly on a Pixel can fail silently on a two-year-old budget Android phone, and someone needs to be testing against that spread periodically, not just at launch.
Backend and API dependency. Almost every business app depends on a backend — for login, content, orders, notifications — and that backend has its own maintenance needs (security patches, database growth, hosting costs) independent of the app itself. A "one-time app cost" quote that doesn't separately account for backend hosting and maintenance is quoting an app that will stop working the day the server it depends on is neglected.
What a Realistic Annual Maintenance Budget Covers
OS compatibility updates. Testing and patching against the newest iOS and Android releases each year, typically once or twice annually as major versions ship. Budget this as a fixed, recurring line item rather than an emergency expense — treating it as reactive maintenance (waiting until something breaks) usually costs more in emergency development time than a scheduled annual pass would have.
Store compliance updates. Keeping up with Apple App Store and Google Play policy changes — privacy labels, permission justifications, target SDK requirements — and resubmitting when required. This is genuinely unpredictable in timing (a policy can change with a few months' notice), which is why it belongs in an ongoing retainer rather than a one-time contract that assumes the app, once approved, stays approved.
Bug fixes and crash monitoring. Crash reporting tools (Firebase Crashlytics and similar) surface real-world failures your testing didn't catch — a specific device model, a specific OS version, a specific network condition. Someone needs to be watching this dashboard and triaging what's worth fixing immediately versus what can wait for the next release; an app nobody is monitoring accumulates silent crashes that show up as declining ratings before anyone on your team notices a problem exists.
Backend hosting and scaling. Server costs scale with usage — more users, more notifications sent, more data stored — and this is a genuinely variable cost that a fixed annual maintenance quote should separate out from development labor, since it depends on your actual usage rather than on a developer's time.
Security patching. Both the app's own dependencies (third-party SDKs for payments, analytics, push notifications) and any backend infrastructure need periodic security updates. A payment SDK with a known vulnerability that isn't patched is a materially different risk on a business app handling transactions than the same gap on a static website.
Feature requests and minor enhancements. Separate from bug fixes: the steady trickle of "can it also do X" requests that come from actually using the app in production. Some maintenance contracts bundle a fixed number of hours per month or quarter for this; others bill it separately from the core maintenance retainer. Clarify which model you're being quoted before signing, since "maintenance" without a defined scope of included feature work is a common source of billing disputes later.
A Rough Annual Range, and Why It's a Range
For a straightforward business app (a handful of core screens, one backend, standard third-party integrations for payments or notifications), a defensible annual maintenance range is roughly 15–25% of the original build cost, covering OS compatibility, store compliance, routine bug fixes, and basic monitoring — not major new features. On a ₹5 lakh build, that's a working estimate of ₹75,000–₹1,25,000 per year, though this should be treated as a planning range to validate against an actual quote, not a number to hold a vendor to without discussing your specific app's complexity.
Apps with heavier backend logic, real-time features (chat, live tracking, video), or multiple third-party integrations (payment gateways, SMS/WhatsApp APIs, mapping services) tend to sit at the higher end or above this range, because each integration is a separate thing that can break when the third party changes its API — and third parties change their APIs on their own schedule, not yours. An app with minimal backend dependency (mostly static content, no real-time features) can sit below it.
The honest caveat: any number given without seeing your specific app's architecture, integration count, and usage volume is a planning range, not a quote. Ask a prospective maintenance vendor to walk through your app's actual dependencies — which SDKs, which APIs, how much backend logic — before accepting a flat percentage figure; a vendor who quotes a maintenance number without asking these questions first is guessing the same way you would be.
The Build-Versus-Maintain Decision Nobody Prices In at Launch
Most business apps eventually hit a point where ongoing maintenance costs more, over a year or two, than a rebuild on current technology would — usually because the original app was built on a framework or architecture that's fallen behind (an old React Native version, a deprecated push-notification service, a backend framework nobody maintains anymore), and every fix is now working around technical debt rather than adding value. There's no fixed timeline for when this happens; it depends on how the app was originally built and how actively it's been maintained in between. But it's worth budgeting for as a real possibility from year two or three onward, rather than being surprised when a maintenance quote for "just fixing a few things" comes back close to a rebuild price — that's usually a sign the underlying architecture, not the specific bug, is the actual problem.
This is also the point where it's worth revisiting whether a native app was the right call in the first place. If your app's core purpose could be served by a fast, installable progressive web app instead — no app store review cycles, no forced OS-update deadlines, updates that ship the moment you deploy them — a rebuild is a natural point to reconsider the platform decision entirely rather than simply rebuilding the same native app on newer technology.
Questions to Ask Before You Sign an App Maintenance Contract
Ask exactly what's included versus billed separately: OS compatibility testing, store resubmissions, crash monitoring, security patching, and feature requests are five different things, and a contract that bundles them vaguely under "maintenance" makes it hard to know what you're actually paying for when a bill arrives.
Ask who owns the crash-monitoring dashboard and how often it's actually reviewed — a maintenance contract that includes crash monitoring tooling but nobody looking at it regularly isn't providing the service it's priced for.
Ask what happens when Apple or Google changes a policy with short notice — is emergency compliance work covered under the retainer, or billed as an extra? This is the scenario most likely to create a dispute, since it's the one maintenance cost that arrives on the platform's timeline, not yours.
Ask for a plain answer on backend hosting costs versus development labor — these should be itemized separately since one scales with your usage and the other doesn't.
Retainer, Pay-As-You-Go, or In-House?
A fixed monthly or annual retainer with your original development partner (or a maintenance-focused agency) gives you predictable budgeting and, usually, priority response when something breaks — the vendor already knows the codebase, which matters when a crash needs diagnosing quickly. The tradeoff is that a retainer priced for "typical" usage can feel expensive in quiet months and can still leave you negotiating extra charges for anything outside its defined scope, which is why the scope needs to be specific rather than a vague "we'll take care of it."
Pay-as-you-go (billing only when work is needed) suits an app with genuinely light, infrequent maintenance needs, but it carries real risk for anything with a hard external deadline — if a Google Play policy change gives you sixty days to comply and your original developer is unavailable or slow to respond because there's no standing retainer, you're negotiating from a weaker position exactly when you have the least time to shop around.
In-house maintenance makes sense once your app is central enough to the business to justify a dedicated developer or small team, typically for apps with continuous feature development, not just upkeep. For most small and mid-sized Indian businesses with one app supporting the core business rather than an app that is the core business, in-house maintenance is usually overkill relative to a retainer with an experienced outside partner — the fixed cost of a full-time hire rarely pencils out against a retainer unless the app needs frequent, ongoing feature work rather than periodic upkeep.
Whichever model you choose, get the response-time expectation in writing: how quickly will a critical bug (payments failing, app crashing on launch) get a first response versus a minor cosmetic issue? A maintenance contract without a stated response-time tier for severity level is a contract that looks the same on paper whether your vendor responds in two hours or two weeks.
Documenting the App So Maintenance Doesn't Depend on One Person
A surprising share of maintenance cost overruns trace back to poor handover documentation rather than the technical work itself — a new developer or agency inheriting an app with no clear record of which third-party services it depends on, which API keys belong to which account, or why a particular workaround exists in the code will spend real, billable time rediscovering things the original developer already knew. Ask your development partner to maintain (and hand over, if you ever switch vendors) a simple living document: which SDKs and APIs the app depends on, who owns each account and subscription, and a changelog of what was changed in each release and why. This single document is often the difference between a smooth vendor transition and a expensive rediscovery project when you eventually need to change who maintains the app.
Frequently Asked Questions
Is 15–25% of build cost accurate for every app?
No — it's a planning range for a straightforward business app with standard integrations, not a universal figure. Apps with real-time features, multiple third-party integrations, or high transaction volume typically need a higher maintenance budget because there are more moving parts that can break independently. Treat any percentage as a starting point to validate against your app's actual architecture, not a fixed rule.
Can I skip maintenance for a year to save money?
You can, but the risk is asymmetric: a website left unmaintained for a year is usually still working; an app left unmaintained for a year risks failing store compliance checks on its next required update, breaking on a new OS release, or being pulled from search visibility for targeting an outdated SDK version. If budget is tight, prioritise OS compatibility and store compliance over new features rather than skipping maintenance entirely.
Do I need a separate contract for backend hosting?
It's worth itemizing backend hosting and scaling costs separately from development labor, since hosting scales with your actual usage (more users, more notifications, more data) while labor doesn't. A maintenance quote that bundles both into one flat number makes it hard to tell whether a cost increase next year is due to more development work or simply more users.
How do I know if my app needs a rebuild instead of continued maintenance?
A useful signal is when routine fixes start taking noticeably longer or costing noticeably more than similar fixes did a year or two earlier, which usually means the underlying framework or architecture has fallen behind rather than the specific bugs being unusually hard. At that point, ask your development partner for an honest comparison of continued-maintenance cost versus rebuild cost over the next two years, rather than authorizing incremental fixes indefinitely.
Is a progressive web app cheaper to maintain than a native app?
Generally yes, because a PWA isn't subject to app store review cycles or forced SDK-version deadlines — updates ship the moment you deploy them, the same as a website. It isn't a universal replacement for a native app (push notification reliability and certain device APIs still favour native on some platforms), but for many business use cases it removes a meaningful share of the maintenance cost that's specific to being distributed through an app store.
Where to Start
Govindani Infotech Pvt. Ltd. is a web development company in Pune that builds both native and progressive web apps for businesses and NGOs, and we quote maintenance as a separate, itemised line from the build — not a vague annual percentage — because clients deserve to know what they're actually paying for each year. If you're evaluating a maintenance quote you've already received, or trying to decide whether your ageing app needs a rebuild, talk to our team on WhatsApp and we'll give you a straight read on it. See our website and app pricing for a sense of where builds and ongoing retainers typically land.
For the underlying build-versus-website decision this sits downstream of, see our guide on choosing between a mobile app and a mobile-optimised website, and for the platform choice if you do build native, our comparison of Flutter and React Native covers the tradeoffs that also affect long-term maintenance cost.