Mobile app maintenance: the cost nobody budgets for.
Launch is the midpoint. Apps stop working for reasons that have nothing to do with your code: a new iOS version, a Play policy change, a payment SDK update, or a certificate that quietly expires.
Kochi, Kerala · Remote worldwide
What maintenance actually includes
Maintenance is not "fixing bugs". In practice it is four ongoing jobs:
- Platform upkeep — new Android and iOS versions, target SDK deadlines, Play and App Store policy changes, privacy requirements.
- Dependency updates — Flutter/Dart or native libraries, payment SDKs, push SDKs, analytics SDKs, each with its own breaking changes.
- Backend and infrastructure — API changes, certificate and domain renewals, server patching, database growth, third-party API deprecations.
- Product work — small improvements, analytics review, conversion fixes, new content or catalogue changes.
Only the fourth is visible to users. The first three are what keep the app installable at all.
Why apps break without changes
Three real examples of apps failing while nobody touched the code:
- Google raises the required target API level. The app stays live but can no longer be updated until the project is upgraded.
- Apple changes a privacy requirement (tracking permission, account deletion, privacy manifest). The next submission is rejected.
- A payment provider deprecates an SDK version or changes webhook behaviour. Checkout starts failing for a subset of users.
None of these are bugs you can see in testing. They are calendar events.
Realistic annual cost
A commonly used planning rule is 15–25% of the original build cost per year. That covers the platform upkeep above. Product growth work sits on top.
| App type | Typical annual maintenance | Notes |
|---|---|---|
| Simple app, one platform | ₹40,000–1,00,000 | Mostly OS and SDK updates |
| App plus backend, payments | ₹1,00,000–3,00,000 | Payment and API upkeep dominates |
| Multi-platform product | ₹3,00,000–8,00,000+ | Several stores, several release cycles |
| OTT or real-time product | Higher and vendor-dependent | Streaming, DRM and RTC vendor updates |
These are planning ranges, not quotes. The number moves with how actively you release and how many third-party services are involved.
Retainer, hourly or in-house
Monthly retainer — a defined number of hours or a defined scope per month. Best for products that are live and need predictable upkeep plus small improvements.
Hourly or per-issue — fine for stable apps with occasional problems, but you carry the risk of a surprise bill when an OS update lands.
In-house — makes sense when you have continuous product work and can keep a developer busy. Even then, most teams keep an external specialist for store releases or a specific platform.
Whichever you choose, the handover documentation from the original build is what makes switching possible. If there is no documentation, you are locked in more than you think.
When to maintain and when to rebuild
Maintain when the architecture still fits the product, the codebase is understood by someone, and the problems are upkeep rather than design. Rebuild when the platform assumptions are wrong (for example, a web wrapper that needs native features), when the codebase cannot be safely changed, or when the product direction has changed substantially.
"The code is old" is not a reason. "Nobody can ship a change without breaking something" is.
Budget for maintenance at the start. A quote that ends at launch is an incomplete quote. Ask what the first year of upkeep is expected to cost before you sign.