An app does not stay finished. Two operating systems ship new versions every year, three libraries it depends on change their minds, and the store rules move without warning. Maintenance is the price of remaining installable.
The tiers, priced
| Tier | Annual cost | What it covers |
|---|---|---|
| Keep the build alive | Rs 40,000 - Rs 1,20,000 | OS compatibility, dependency updates, store submissions |
| Standard support | Rs 1,00,000 - Rs 3,00,000 | Above plus crash fixes and ten to fifteen hours of changes |
| Priority support | Rs 2,50,000 - Rs 5,50,000 | Faster response, thirty hours, release support each cycle |
| Product upkeep | Rs 5,00,000 - Rs 8,00,000 | Named team, analytics review, quarterly releases |
| Rebuild of a failing module | from Rs 6,00,000 | Replacing the part that keeps breaking |
A rough rule from our own projects: an app built for Rs 12,00,000 needs Rs 1,80,000 to Rs 3,00,000 a year to stay healthy. That figure excludes backend hosting and third-party services.
What the cheapest tier actually protects
Keep-the-build-alive is not a support contract in the way most people mean it. It is insurance against the app becoming un-installable.
It covers the annual operating system release, the libraries that break with it, and the store submission that follows. It does not cover new features, and it does not cover the bug that a user reports on a Tuesday.
The word insurance is doing the work there. Businesses buy the cheapest tier expecting a helpdesk, then discover the helpdesk is a change request. Read the scope, not the price.
Retainer, ad hoc or rebuild
Retainer suits an app with users and a roadmap. You are buying continuity: the same people, the context they hold, and a response time.
Ad hoc suits an app that is stable and rarely touched. You pay per change, which is cheap in a quiet year and expensive in the year the store changes its rules.
Rebuild suits an app whose foundation is the problem. Patching a broken architecture costs more each year, and there is a point where the annual fixes exceed the cost of replacing the module.
The signal is simple: if more than half the retainer is spent on the same area every year, stop maintaining it and replace it.
What forces the annual spend
Three things, and none of them is your own code.
The operating system releases. Each year brings a new version, and a new set of behaviours that used to work.
The deprecation cycle of the frameworks underneath. A library that was current two years ago may now be two majors behind, and the upgrade is not a one-line change.
Store policy. Privacy manifests, permission prompts, background execution rules and payment policies. Each is a small piece of work with a hard deadline.
None of those are optional, which is why the cheapest honest answer to “can we skip maintenance this year” is no.
Crash monitoring, and what it is not
Crashes are the easiest failure to see and the least representative of what users experience. A crash closes the app; a slow screen, a failed payment and a form that silently drops a field do not, and none of them appear in a crash dashboard.
So a tier that promises a crash-free rate is promising the visible part. Ask instead whether anyone reviews session behaviour, store reviews and support tickets, because that is where the quiet failures surface.
The practical split is this: crashes get fixed because they are loud, and everything else gets fixed only if the tier includes time to read what users wrote.
How to size the tier
Count the users, the releases and the revenue.
An internal app with fifty users and two releases a year sits at the bottom. A consumer app with releases every month and payments in it sits near the top, because a bad release costs money within hours.
Do not buy priority support for an app that would survive a week offline, and do not buy the cheapest tier for one that takes payments.
What to ask before signing
Who exactly is on call, and in which hours. What the response time is for a crash versus a question. How change hours roll over, if at all. And what happens to the app if you stop paying: does the code come with a build you can run yourself?
That last answer decides whether you are renting continuity or owning it.
FAQ
Is maintenance included in the build price? No. Builds end at handover, and the first year of support should be quoted before you sign the build.
Can we reduce the tier after a year? Yes, and it is common once releases slow. Ask what the exit looks like at the start.
Do we pay for store fees separately? Yes. Developer account fees go to the store directly from your account, and we do not handle them.
What happens if we skip a year? The next upgrade is bigger, and the app may already be unreachable on the newest phones by the time you return to it.
Is a rebuild ever cheaper than three years of support? At the top tier, yes. Three years of priority support can cost more than rebuilding the part that keeps failing.
App support in Noida
We run app support from Noida with the on-call hours written into the agreement rather than described on a call. Call 7840002466 or list the platforms through the contact page.
To compare build costs before deciding to maintain or replace, see the mobile app cost by industry page.
