In 2026, maintaining an app in India costs roughly 15,000 to 35,000 rupees a month to keep a stable app alive, 35,000 to 75,000 a month with active releases, and 75,000 to 2 lakh and above when the app is the business. The rule of thumb behind those bands is 15 to 25 percent of the build cost per year, and it holds up. What the rule does not tell you is what the money buys, which is why so many first-time app owners treat maintenance as optional until the year it batches up. So this guide does something the ranking pages do not: it itemises a year in which nothing happened.
The quick-reference table
| Level | Monthly (INR) | Monthly (USD) | What it covers | Fits |
|---|---|---|---|---|
| Keep-alive | 15,000 to 35,000 | $180 to $420 | Monitoring, crash fixes, OS and store compliance, security patches, a fixed number of engineering hours | A stable app with few integrations and no roadmap |
| Active | 35,000 to 75,000 | $420 to $900 | The above, plus dependency upgrades on a schedule, integration changes handled before they break, and a monthly release with small improvements | An app customers or staff use every day |
| Growth | 75,000 to 2 lakh and up | $900 to $2,400 and up | A part-time team: features, performance work, experiments, tighter response times | An app the revenue depends on; shades into a dedicated team |
The percentage rule maps onto the same bands. A 15 lakh app at 15 to 25 percent is 2.25 to 3.75 lakh a year, or roughly 19,000 to 31,000 a month, which is the keep-alive tier with a little room for improvements. That is the check to run on any quote: divide the annual figure by what the app cost to build, and if the answer is far outside 15 to 25 percent, something is either missing or padded.
These are engineering costs. The app also has a monthly bill that is not engineering, covered further down, and the two are usually quoted separately.
What maintenance actually is
Maintenance is not a retainer for redesigns. It is the cost of the world changing under a finished app. The app you launched works on today's operating systems, today's payment gateway API, today's versions of forty libraries, and today's store policies. Every one of those moves on its own schedule, and none of them asks you first.
Two of those deserve a sentence each. Apple ships a new iOS every September, and apps submitted after the following spring have to be built with that release's toolchain, so every app gets rebuilt at least once a year whether it changed or not. Google requires apps to target a recent Android version, with a deadline every year at the end of August, and apps that fall too far behind stop being offered to new users on newer phones. Neither of these is optional, and neither is in the build quote.
Where the money goes: a year in which nothing happened
Take a consumer app built in Flutter with a Node backend, about 15 lakh to build, with payments, SMS one-time passwords, maps and push notifications. No new features all year. Here is what the year costs anyway, the way we would estimate it.
| Work package | Person-days a year |
|---|---|
| The iOS release in September: test on the new version, fix what broke, rebuild and resubmit | 3 |
| The Android release and the Play target-version deadline | 2 |
| Dependency and security updates, done quarterly rather than in one frightening batch | 4 |
| Third-party changes: a payment gateway API version, the SMS provider, the maps SDK | 3 |
| Store policy work: data safety forms, privacy labels, the in-app account deletion both stores now require, the occasional rejected build | 2 |
| Renewals: certificates, push credentials, signing keys, the domain, store listings | 1 |
| Monitoring, triage and crash fixes, a few hours a month | 6 |
| Backend care: database maintenance, backups restored as a test, a hosting bill review | 3 |
| Total | 24 |
At a blended 12,000 rupees a person-day, which is where maintenance work sits for an experienced Indian team, that is about 2.9 lakh a year, or 24,000 a month: 19 percent of the build, inside the rule of thumb and inside the keep-alive band. Add a monthly release with small improvements, another 12 to 20 days a year, and you are in the active band. The rule of thumb is not a convention someone made up; it is this table, rounded.
The monthly bill that is not engineering
| Cost | Typical monthly size | What moves it |
|---|---|---|
| Hosting, database and storage | 3,000 to 40,000 rupees | Users, data and how much runs on the server |
| SMS, WhatsApp, maps, push, email | 2,000 to 30,000 rupees | Metered with usage; SMS one-time passwords are the usual surprise |
| Monitoring, crash reporting, analytics | Free tiers to 5,000 rupees | Event volume and how many seats need dashboards |
| Store accounts | Apple $99 a year, Google $25 once | Nothing, but the Apple renewal lapsing takes the app down |
| Domain, certificates, signing | A few thousand a year | Nothing, if someone owns the calendar |
| AI features, if any | Per request, from a few thousand | Usage, and it grows with success |
The AI line is the one 2026 budgets most often miss. An ordinary feature costs nothing to run; an AI feature has a bill on every use, and the arithmetic is in what an AI agent costs to run. The full list of costs that never appear in a build quote is in our app development cost guide.
The five things that move the price
- How many outside systems the app depends on. Every gateway, login provider, courier, map and messaging API is a partner who will change something this year. Five integrations is a normal app; fifteen is a maintenance load of its own.
- Native or cross-platform. Two native codebases mean two of every platform task in the table above. Flutter or React Native halves that, at the cost of waiting for the framework to catch up with each OS release; the trade-off is in Flutter vs React Native vs native.
- Test coverage. An app with automated tests can be upgraded in a day and released with confidence. An app with none needs a person to click through everything after every change, and that is the difference between the keep-alive and active bands on its own.
- How far behind it already is. An app kept current costs the table above. An app that skipped two years costs a revival first, which is the next section.
- Response time. Same-day fixes for payment failures need someone on call. Next-release fixes do not. The tighter the promise, the more of a person's month you are paying for whether or not anything breaks.
What it costs to not maintain an app
Skipping maintenance does not save the money; it batches it, with interest. An app untouched for two years typically arrives with libraries several major versions behind, a build that no longer compiles on current tools, a payment integration on a retired API version, expired credentials, and a store listing that new users on new phones cannot see. Before a single new feature can ship, someone has to bring all of that forward at once, and every step depends on the previous one.
That revival is usually several weeks of engineering, and it routinely costs more than the two years of keep-alive maintenance it replaced, because upgrading forty libraries one at a time over two years is cheap and upgrading them all in one go is not. The revival also lands at the worst possible time, which is the moment the business finally wants something new. Budget the percentage or budget the revival, but budget one of them.
How maintenance is bought
| Model | How it works | Best when | Watch for |
|---|---|---|---|
| The warranty period | A month of fixes included after launch | Every project should have one | A "warranty" that covers only bugs the agency agrees are bugs |
| Pay as you go | Hourly, typically 1,500 to 4,000 rupees, when something breaks | A stable app with no roadmap and a patient user base | Nobody watching between incidents, so the OS release lands as an emergency |
| Monthly retainer with response times | A fixed monthly fee for defined hours, monitoring and a response promise | Most apps in real use | Unlimited support that is quietly limited; ask for the hours |
| Dedicated engineer or team | One or more people on the app every month | An app that is the business, with a permanent backlog | Paying for a full person when the app needs a third of one |
We include the first, offer the third after it, and move clients to the fourth when the backlog says so; the monthly numbers for that are on our dedicated teams page. The wrong model is the second one for an app people rely on, because pay-as-you-go maintenance is emergency maintenance by another name.
What the response promise should say
A maintenance contract without severity levels is a hope. The useful shape is three levels, with examples.
| Severity | Example | Response | Fix |
|---|---|---|---|
| Critical | The app will not open, payments are failing, data is exposed | Within hours, including outside office hours if the contract says so | Same day, a workaround first if needed |
| Major | A main feature is broken for many users, a store rejection is blocking a release | Within one working day | Within days, in a hotfix release |
| Minor | A cosmetic defect, an edge case affecting few users | Within a few working days | In the next scheduled release |
Response is not resolution, and the contract should define both. It should also say what happens when the cause is a third party, such as a gateway outage or a store review delay, because those are the incidents where the agency can do least and the client is most anxious.
How to read a maintenance quote
Six checks, ten minutes.
- Find the hours. "Unlimited support" always has a practical limit. Ask what it is, in hours a month or issues a month.
- Find the severity definitions. If critical, major and minor are not defined with examples, every incident will be a negotiation.
- Separate response from resolution. An acknowledgement in an hour is not a fix in an hour.
- Read the exclusions. New features, redesigns, OS migrations, new integrations, hosting and third-party bills are usually excluded, and should be listed rather than discovered.
- Ask for the monthly report. Incidents, releases, dependency updates, backup checks and what is coming next. If there is no report, there is no evidence the work happened.
- Ask who holds the accounts. The stores, the cloud, the domain and the repository should be in your company's name, whoever maintains the app. Our mobile app development page says the same for builds, for the same reason.
How to spend less without a fragile app
- Fewer dependencies. Every library is a future upgrade. Choose boring, well-maintained ones and remove the ones a single feature needed.
- Small, regular updates. A quarterly dependency pass is an afternoon. The same work after two years is a fortnight.
- Automated tests and a build pipeline. They turn every upgrade from a manual click-through into a green tick, and they are the largest single saving in the active band.
- Managed services over self-run servers. A managed database patches itself. One on a rented server patches itself only if someone remembers.
- Monitoring from day one. Crashes and slow screens found by a dashboard cost hours; found by one-star reviews they cost users.
- Feature flags for integrations. When a partner API breaks, switching the feature off in a minute beats an emergency release.
- Design the checks into the build. This website fails its own build if a page is missing metadata, which is why the checks that caught the old site's problems cannot be forgotten; the story is in the rebuild case study.
Questions people ask
How much does app maintenance cost per month in India?
15,000 to 35,000 rupees a month keeps a stable app alive with monitoring, crash fixes and platform compliance. 35,000 to 75,000 adds scheduled upgrades and a monthly release with small improvements. Apps the business depends on run 75,000 to 2 lakh and above, which is really a part-time team. Hosting and third-party services are on top.
How much does it cost to maintain an app per year?
Budget 15 to 25 percent of the build cost per year for engineering, so 2.25 to 3.75 lakh a year for a 15 lakh app, plus the running bill for hosting and services. The itemised year above shows where that money goes even when no features are added.
What is included in app maintenance?
Platform updates for each iOS and Android release, store policy compliance, dependency and security updates, crash monitoring and fixes, backend care including tested backups, renewals of certificates and credentials, and a defined response when something breaks. New features, redesigns and new integrations are usually separate, and a good contract says so.
What happens if I stop maintaining my app?
Nothing, for a while, which is what makes it tempting. Then an OS release breaks a screen, the gateway retires an API version and payments stop, the store hides the app from new users for targeting an old Android version, and a certificate lapses. Bringing the app forward after two years is a multi-week revival that typically costs more than the maintenance skipped.
How much does it cost to maintain an app like Uber or Zomato?
At that scale, maintenance is not a retainer; it is hundreds of engineers and a bill in crores a year, and the question does not really apply. For an app "like" one of those built as a first version for 20 to 40 lakh, the same rule holds: 15 to 25 percent a year, so 3 to 10 lakh, before hosting and messaging costs that scale with users.
Can we maintain the app ourselves?
Yes, if someone on your team can build and release it on both platforms and is willing to own the calendar of OS releases, deadlines and renewals. The handover should include the code, the accounts, the documentation and the test suite. Most companies without an engineering team find that a small retainer costs less than the first missed deadline.
How often should an app be updated?
At minimum once for each iOS and Android release, so twice a year, plus security patches when they matter. In practice a small monthly release is cheaper and safer than two large ones, because each change is small enough to understand and roll back, and users stop seeing the app as abandoned.
Getting a real number
Every app we build includes a month of fixes after launch, and after that a maintenance plan sized to the table above rather than a percentage pulled from the air. If you have an app someone else built, send us a few sentences about it, when it was last updated and what it depends on, and we will tell you within one working day whether it needs a plan or a revival, and roughly what each costs. The process is on our mobile app development page.