App maintenance after launch: what quietly breaks, and what it really costs to keep your app alive in 2026

Everyone celebrates launch day. The app is live, the icon is on the phone, the first order comes in. It feels like the finish line after weeks of work and money spent.

It is not the finish line. It is the day the app starts aging.

I have shipped apps for fifteen years, and the hardest conversation I have with a new owner is not about the build. It is the one six months later, when they message me confused: "It was working perfectly. I didn't change anything. Why did it suddenly break?" Nobody warned them that an app is not a thing you finish and forget. It is a living thing that needs feeding, or it slowly stops working.

This post is the warning I wish every owner got before they spent a rupee. No jargon, no scare tactics. Just the honest list of what breaks after launch, why it breaks (it is almost never your developer cheating you), and what it actually costs to keep your app alive and healthy in India in 2026, with real numbers you can plan around.

An app is not a product you finish — it is a garden you keep

Here is the one idea that makes everything else make sense: your app does not live on its own island. It sits on rented land, and three different landlords keep changing the rules.

The first landlord is the phone. Apple and Google release a big new version of iOS and Android every single year, plus smaller updates in between. Your customers' phones update themselves automatically. So a screen that worked perfectly last year can start behaving oddly on this year's phones, because it was built for last year's rules.

The second landlord is the app store. Both the Apple App Store and the Google Play Store change their rules constantly, and they enforce them. What was allowed when you launched may need a change today just to stay listed.

The third landlord is every outside service you plugged in. Almost no app is fully self-contained. If yours takes payments, sends an OTP, shows a map, or sends a notification, it is quietly leaning on another company's service. Those companies change how they work, and sometimes what they charge, on their own schedule, not yours.

Your app's own code can sit untouched and still stop working, because everything it stands on kept moving. That is the whole game. Once you accept that an app is a garden you keep, not a wall you build once, the costs and the work stop feeling like a betrayal and start feeling like normal upkeep, the same way a shop needs cleaning and a car needs servicing.

The bills nobody added up before you started

Let us start with the part that is easiest to plan: the fixed and recurring bills. These are not surprises, but most owners never see them totalled in one place before they commit. Here they are, with real 2026 numbers for an Indian business.

A few of these deserve a plain-English word, because the details bite people.

Apple charges you every year, and it is not optional. The Apple Developer Program is about US$99 a year, which lands around ₹8,700 on an Indian card after conversion and GST (Apple's own page confirms the US$99 fee). Here is the trap: if you forget to renew it, Apple pulls your app from the store until you pay. Google Play is friendlier, a one-time US$25 (about ₹2,200) that lasts forever. But the Apple renewal is a yearly alarm you must set.

The backend is the sneaky one. If your app saves anything, orders, bookings, user logins, that data lives in a database somewhere, and someone pays for that somewhere. Two popular choices are Google's Firebase and Supabase. Both have a genuinely free tier that is enough for a small app at the start. Firebase's free plan gives you tens of thousands of database reads a day, and Supabase's free plan gives 500 MB of storage and up to 50,000 monthly active users. But as you get busier, you cross those free limits and start paying. Supabase's paid plan begins at US$25 a month (about ₹2,200), and Firebase bills by usage on its pay-as-you-go plan. This is a good problem, it means people are using your app, but it is a real, growing bill, not a one-time cost.

The payment gateway takes a slice of every sale. If you sell through the app, a service like Razorpay processes the money and charges about 2% plus GST per successful transaction across cards, UPI, netbanking and wallets (per Razorpay's pricing guide). On ₹1,00,000 of monthly sales that is roughly ₹2,000 gone in fees. It is worth it, but you must price it in, not discover it.

Add the fixed pieces up for a typical small-business app on both platforms, and you are looking at a floor of roughly ₹12,000 to ₹15,000 a year in unavoidable running costs before a single hour of update work, and more as your usage and sales grow. That is the number to keep in your head. Now let us talk about the work.

What actually breaks after you launch (and why it is not your developer's fault)

When an owner tells me "it just broke on its own," one of five things has almost always happened. Knowing these five means you will never be blindsided, and you will know the difference between normal upkeep and a developer who genuinely dropped the ball.

1. The platforms change the rules under you (every single year)

This is the biggest one, and it is completely out of your control. Both stores force apps to stay current, and they mean it.

On Android, Google runs an annual deadline. To keep publishing updates and stay fully visible, your app must "target" a recent version of Android. From 31 August 2026, new apps and updates must target Android 16, and apps that fall too far behind stop being visible to new users on newer phones (Google's Play Console documents this requirement). Your existing users are not thrown off, but your app quietly disappears from the store for anyone shopping on a new phone. It does not crash. It just goes invisible, which is worse, because you may not even notice.

On Apple, the rule is about neglect. Through its App Store Improvements process, Apple flags apps that have not been updated in about three years and get almost no downloads, and after a warning and a grace period, removes them (TechCrunch reported the refreshed 2026 policy). An app you build and never touch again is on a slow timer.

The honest takeaway: even an app that needs no new features needs a small "keep it current" update roughly once a year, purely to satisfy these rules. That is not padding. That is rent.

2. Your app's own parts quietly go out of date

Every app is built out of ready-made building blocks, called libraries, that other people maintain and improve. Think of them as ingredients you did not grow yourself. Over a year, those ingredients get new versions, some for security, some for compatibility with new phones. If you never refresh them, your app is slowly running on stale ingredients.

Most of the time this is invisible for a while, then one day a stale block clashes with a new phone or a new store rule, and something breaks. Keeping these blocks reasonably fresh is quiet, boring work that prevents loud, expensive problems. It is exactly the kind of thing a once- or twice-a-year update window is for.

3. The outside services you plugged in change or raise prices

Remember the third landlord. The services your app leans on evolve on their own schedule, and two things happen.

First, they change how they work. A service can retire an old way of doing things and require you to switch to a new one by a deadline. When that deadline passes, the old way stops working, and the feature that depended on it breaks, even though you changed nothing.

Second, they change what they charge. A real, recent example: Google Maps used to give every developer a US$200 free monthly credit that covered light use. Google removed that credit on 1 March 2025 and replaced it with smaller per-feature free limits (Google's own billing FAQ explains the change). Apps that quietly relied on that free credit suddenly had a bill. Nobody at those businesses did anything wrong. The ground moved.

You cannot prevent this. You can only stay aware of what your app depends on, so a change is a small planned fix and not a mystery outage.

4. Real users do things your test phone never did

Before launch, you and your developer test on a few phones, doing sensible things. Then real customers arrive, on hundreds of different phones, with weak network, old Android versions, full storage, strange keyboards and typos you never imagined. They find the edges you never tested.

This is why the first few months after launch usually need the most attention, and why the maintenance cost in year one runs higher than later years. It is not that the app was built badly. It is that reality is bigger than any test. A good build plus a responsive first few months is how an app goes from "works in the demo" to "works for everyone."

5. Small security holes open up over time

A lock that is safe today can become pickable tomorrow, because someone somewhere finds a new trick. Security is not a one-time setting; it is an ongoing patch cycle. The building blocks in point two get security fixes, and if you never apply them, your app keeps a known hole open.

This matters most if your app holds customer data, names, phone numbers, addresses, orders. Leaving that data on an un-patched app is a real risk, and under India's data protection rules, it is your legal responsibility, not your developer's. I wrote about how easily this goes wrong, especially with AI-built apps that leave the database wide open by default, in my day-long experiment letting AI build a full app. The short version: security is a thing you maintain, not a thing you finish.

The four kinds of maintenance, in plain English

People in software split maintenance into four buckets. You do not need the jargon, but the four ideas help you understand what you are paying for, so here they are in simple words.

• Fixing what broke. Something stopped working and needs repair. A payment fails, a screen crashes on a certain phone. This is the obvious kind.
• Keeping up with change. Nothing is "broken," but the world moved, a new Android version, a new store rule, a changed outside service, and the app must be updated to match. This is most of the yearly work, and the part people forget.
• Making it better. Small improvements based on what real users struggle with. A confusing button, a slow screen, a missing filter. Not new features exactly, just polish that keeps people happy.
• Preventing future trouble. The boring, invisible work: refreshing building blocks, applying security patches, cleaning up. Nobody sees it, and it is the cheapest kind because it stops the expensive kind from ever happening.

A healthy maintenance plan spends most of its money on the last two, keeping up and preventing, so it rarely has to spend on the first, emergency fixing. An app with no plan spends nothing until something breaks, then pays a premium to fix it in a panic. Prevention is genuinely cheaper. I have watched both play out for a hundred clients, and the ones who budgeted a little every year always spent less in total than the ones who ignored it and firefought.

So what does it really cost per year?

Here is the number the whole industry quietly uses, and now you will too. Serious software-cost research, including work summarised by the Consortium for Information and Software Quality (CISQ), puts steady-state annual maintenance at about 15 to 20 percent of the original build cost, every year. The first year usually runs higher, because that is when reality finds all the edges.

Let me make that concrete with a fully worked example, the kind I actually quote.

The example: a home bakery's ordering app. Say a Noida home baker gets a simple but real app built, menu, order form, booking calendar, admin view, saved to a proper database, on both Android and iPhone. A fair build price for that is around ₹1,50,000. (For how build prices are set, see what an app really costs to build in India.)

Now the yearly running cost, laid out honestly:

A few honest notes on that table. The backend starts near free and climbs only as real orders flow in, which is a good sign. The update work is the biggest lever, and it is a range because it depends on how much changes that year and whether you want small improvements or just "keep it alive." Payment fees are not really a cost of the app, they are a cost of making sales, and they scale with your revenue.

The point is not the exact figure. The point is that a ₹1,50,000 app is roughly a ₹45,000-a-year responsibility, and if nobody told you that before you built it, you were shown half the price. Plan for the whole thing and there are no nasty surprises.

The traps that get an app quietly pulled from the store

Some maintenance failures do not just cause a bug. They get your app removed, and you often do not notice until a customer says "I can't find your app anymore." These are the ones to guard against hardest.

The Apple renewal you forgot. Miss the yearly ₹8,700 payment and your app comes off the store until you pay. Set a calendar reminder a month before, every year.

The Android "too old" cliff. As covered above, if your app stops targeting a recent Android version, Google hides it from new users on new phones. You keep your existing users but lose all new ones silently. The fix is the yearly "keep it current" update. Google usually emails a warning and offers a short extension, but you have to act.

The Apple three-year neglect rule. An app with no updates for about three years and barely any downloads gets flagged and, after a warning, removed. One small update a year resets this clock permanently.

The account you cannot get into. This is the quiet killer, and it is not Apple's or Google's fault, it is an ownership mistake. If your developer created the Apple, Google, domain or backend accounts under their own email "to make it easy," then the day you part ways, you can lose control of your own app. I have seen businesses effectively held hostage over a login. It is completely preventable, and I will show you how in the next section.

If you want the full picture of how store rules and reviews actually work, I broke it down in what really happens after you submit to the Play Store and App Store.

A simple maintenance plan any owner can run

You do not need to be technical to keep your app healthy. You need a handful of habits and one small budget. Here is the exact plan I give clients.

1. Own every account yourself. This is the most important rule in this whole post. The Apple Developer account, the Google Play account, the domain, and the backend must all be registered under your own email and your own name, with you as the owner. Let your developer be added as a helper if needed, but you hold the keys. Do this on day one. If it was not done, fixing it is worth every bit of hassle. An owner who controls their accounts can change developers, move providers and survive any fallout. An owner who does not is one bad relationship away from losing their app.

2. Put the renewals on a calendar. Apple's yearly fee, your domain renewal, and any yearly service. Set a reminder one month before each. This alone prevents the most common "my app disappeared" panic.

3. Book two update windows a year. Not random emergencies, planned check-ups. Twice a year, have someone update the building blocks, apply security patches, make sure the app targets the current Android and iOS, and fix any small issues users reported. For a simple app this is a few hours of skilled work each time, not a full-time job. Think of it as servicing your car before the long trip, not after the breakdown.

4. Turn on basic monitoring. Ask your developer to add free crash reporting (tools built into Firebase and the app stores do this). Then you find out about a broken screen from a dashboard, not from an angry customer. It costs nothing and changes maintenance from reactive to calm.

5. Keep your data backed up. Make sure your database is backed up automatically, so a mistake or a mishap never wipes your orders and customers. Most backend providers offer this; confirm it is on.

6. Keep a small maintenance fund. Set aside the yearly number from the table above, roughly 15 to 20 percent of your build cost, in a separate line in your budget. When a fix is needed, it is a planned decision, not a cash-flow crisis. Owners who fund maintenance make calm choices. Owners who do not, delay fixes until they become emergencies, which always cost more.

Do these six things and you have covered ninety percent of what goes wrong, without hiring anyone full-time.

How to buy maintenance without overpaying

You have three sensible ways to pay for the technical part, and the right one depends on how much your business leans on the app.

On-call, per-fix. You pay only when something needs doing. Cheapest if your app is simple and stable, but you are at the back of the queue when you have an emergency, and prices per visit are higher. Fine for a low-stakes internal app.

A yearly plan or retainer. You pay a fixed amount for an agreed amount of upkeep, usually including the two update windows, the "keep it current" work, and priority when something breaks. This is what I recommend for any app that real customers or real revenue depend on. It turns a scary variable cost into a predictable line item, and it means someone is actually watching your app, not just waiting for your call.

Bring it in-house. Only worth it once your app is central enough to need constant work, which for most small businesses is a long way off. A part-time developer or a studio on retainer is almost always cheaper than a full-time hire until you are genuinely at scale.

Whatever you choose, get the yearly cost and the response time in writing before you commit. A builder who will not put a maintenance number on paper is telling you something. A good one does it happily, because they would rather you have a working app in a year than a broken one and a bad memory.

The honest trade-offs

Let me be straight about the tensions, because there is no perfect answer.

Spending nothing on maintenance is tempting and works, right up until it doesn't, and then it fails at the worst time, usually when the app is finally getting traction. Spending too much is also a real risk: you do not need a big monthly retainer for a simple, stable app that a few staff use internally. Match the spend to the stakes. An app that takes customer payments and holds personal data deserves real, funded upkeep. A simple booking tool for your own team can run on the cheap six-habit plan and a once-a-year check-up.

The other honest trade-off is simplicity. The single best way to cut your maintenance cost is to build a simpler app in the first place. Every extra feature, every extra outside service you plug in, is one more thing that can break and one more thing to keep current. The apps that are cheapest to maintain are the ones that do a few things well, not the ones that try to do everything. If you are still at the planning stage, that is the highest-value decision you can make: build the boring, focused version first.

The apps that survive for years are almost never the fanciest ones. They are the ones with an owner who understood, from the start, that an app is a garden you keep, not a wall you build once, and who budgeted a little every year to keep it alive.

If you would rather not manage any of this yourself, keeping an app healthy, current and safe, on a predictable yearly cost, is exactly the kind of ongoing work we handle at the Studio; you can see how we build and look after apps here. But even if you never work with us, do the six habits above. They will save you from the mistakes I watch owners make every single week.