The quote said eighteen lakh and four months. Nobody lied. The app shipped, it worked, everyone was pleased.
What the quote did not say is that the same app costs money every year afterwards whether or not a single new feature is ever added — and that this figure, over a normal app lifetime, exceeds what you paid to build it.
The costs that arrive whether you do anything or not
This is the category that surprises people, because it is not optional and it produces nothing a user would notice.
OS releases, twice a year, forever. iOS and Android each ship a major version annually, and each one changes something. A permission model tightens, an API is deprecated, a background execution rule changes, a UI convention shifts. Your app must be tested against each release and usually adjusted. Skip a cycle and you accumulate debt that eventually forces a larger project.
Store policy changes. Both stores raise their minimum requirements periodically — target SDK versions, privacy declarations, data disclosures. Miss a deadline and your app stops accepting updates, then eventually gets delisted. These are non-negotiable and they arrive on someone else's schedule.
Dependency churn. Every library in your build has its own release cycle and its own security advisories. A framework major version can turn into a fortnight of untangling, and the longer you defer it the worse it gets — the gap between your version and current only ever widens.
Certificates and accounts. Developer programme fees, signing certificates, push notification credentials. Each expires, and each expiry breaks something loudly if nobody was tracking it.
None of this ships a feature. All of it is required to remain in the stores.
Fig. — Only the last band is optional. The rest arrives on someone else's schedule.
The running costs
Backend infrastructure is the obvious one, and it is usually modest at low usage and non-linear at scale. The mistake is budgeting from launch-week numbers rather than from the load you are hoping for.
Third-party services accumulate quietly. Push notifications, analytics, crash reporting, maps, SMS or email delivery, authentication, image hosting. Each is inexpensive alone. Together they are a monthly line item most teams cannot itemise from memory, and it grows with usage rather than staying flat.
Monitoring is the one teams skip and then regret. Crash reporting and performance monitoring cost something; not having them means learning about a crash from a one-star review a week after it started.
The work nobody scopes
Crash triage. Even a well-built app produces crashes on device and OS combinations nobody tested. Somebody has to look at them weekly, decide which matter, and fix those. Ignore it and your store rating erodes in a way that is expensive to reverse.
Support escalations. Not first-line support — the ones that reach an engineer because the answer requires reading logs. Low volume, high interruption cost.
Store review rejections. Even routine updates get rejected sometimes, occasionally for reasons that require a real conversation with a reviewer. Unpredictable and unavoidable.
Security patching. A vulnerability disclosed in a library you depend on is not scheduled work. It is work you do that week.
Who does the work matters more than what it costs
The cost question usually gets asked before the harder one, which is who is going to do this.
The agency that built the app is the default answer, and the arrangement works if you agree the terms up front. What causes trouble is the gap: the project ends, the retainer was never signed, and six months later an OS release breaks something. Now you are negotiating an emergency engagement with a team who have moved on to other clients, at whatever rate the urgency justifies.
Hiring in-house makes sense past a certain size, and that size is larger than most founders assume. One mobile developer maintaining one app is expensive per unit of work and fragile — when they leave, nobody else can ship a release, and you discover the signing certificate was on their machine.
The pragmatic middle for most small products is a modest ongoing retainer with whoever built it, sized for the predictable work — OS releases, store deadlines, dependency updates, crash triage — with feature work quoted separately. That converts an unpredictable emergency cost into a boring monthly one, which is the whole point.
Whatever you choose, make sure the accounts are yours. The developer programme membership, the signing certificates, the backend infrastructure, the third-party service accounts. Teams that skip this discover during a handover that their app legally belongs to a former contractor's account, and that conversation is expensive.
How to budget for it honestly
The common industry heuristic is fifteen to twenty percent of the original build cost per year for maintenance alone, before any new features. That figure varies with complexity, but it is a far better planning assumption than the zero most first-time budgets implicitly use.
A more useful way to think about it: assume a three-to-five-year life, and expect total cost of ownership to land somewhere near double the build cost. If that changes whether the project makes sense, better to know before you start than in year two.
And budget for the rewrite. Every app reaches a point where the accumulated OS changes, dependency drift, and design debt make incremental work slower than starting over. Typically that is four to six years. It is not a failure of engineering; it is the normal lifecycle, and pretending otherwise just means the rewrite happens as an emergency rather than a plan.
What actually reduces the bill
Fewer dependencies. Every library is a permanent maintenance obligation in exchange for a temporary saving. Pulling in a package to avoid writing forty lines is usually a bad trade over five years.
Automated tests around the parts that break silently — payments, authentication, sync, anything with money or state. You are not testing for correctness so much as for the OS update that changes behaviour underneath you.
A real CI pipeline. If shipping a fix requires a specific person with a specific laptop configuration, your response time to an urgent problem is measured in that person's availability.
And fewer features. This is the one nobody wants to hear. Every screen you ship is a screen that needs testing against every OS release for as long as the app exists. The cheapest feature to maintain is the one you decided not to build, and the second cheapest is the one you removed when the analytics showed nobody used it.
Building and maintaining apps that stay cheap to own is the sort of work we do at CODT.
