How much does it cost to maintain an app?
The engineering work a custom product needs after launch.
Almost every answer to this question is a percentage. Fifteen to twenty-five percent of the build cost, every year, forever. In our July 2026 check, eleven of fourteen AI assistant answers came back with a percentage. The maintenance calculators are mostly built on it. Somewhere behind it all sits a rule of thumb old enough to have grandchildren.
We run custom software products for a living, and we have since 2012. And we cannot give you one percentage, because across fourteen years of doing this, we have not found one that plans these products well. What we can give you is how it breaks down: what the money actually goes on, when it arrives, and the parts nobody puts in the budget.
The answer in engineering time
There is no honest single number for what it costs to maintain an app, but there is an honest range. Across the products we run, built for €50,000 to €400,000 and some beyond, steady state settles at an average of 2 to 4 days of engineering a month per product. The first 3 months after launch run heavier: expect 1 to 2 weeks of near-full-time work as real users arrive, sometimes longer, then a taper back to the steady rhythm. On top of that rhythm come lumps: an operating system release, a library reaching end of life, an app store policy shift.
The lumps do not average nicely. That is exactly why the percentage rule misleads.
To turn the days into money, multiply them by the blended day rate of the team that will run your product. A day is team time, not one engineer's, and the range is an average across uneven months. The days are engineering effort. Hosting, licences and other third-party charges are separate cash costs and sit outside them.
Basis: our own post-launch operating experience running products since 2012. A practitioner range, not a survey or a market benchmark.
A product in the market is a running commitment, not a finished artefact. Here is what the commitment is made of:
- Fixing what real users find
- Keeping up with the platforms
- The store is a moving target
- The blame you absorb
- The improvements you choose to fund
What the money actually goes on
Fixing what real users find. No plan survives contact with real users. They surface things that were impossible to catch in testing, and they use the product in ways you did not design for. On Android especially, the sheer number of devices makes edge cases likely beyond whatever device matrix you launched against. The first week can even be quiet, mostly tidy-up from testers and early users; then real users arrive and the reports come fast, through the monitoring on one side and the reviews, forums and help desk on the other. If you are shipping a major update to an established system, expect that pace from day one. This is why launch means switching on crash reporting, monitoring, review tracking and a help channel, and actually watching them. Finding out from a one-star review is finding out late. An experienced team has been through this before: set up in advance, knowing where to look, reacting calmly, and doing the worrying for you.
Keeping up with the platforms. The world moves underneath a live product. Operating system releases arrive on the platforms' schedule, not yours, and you need to be ready before your customers update, not after. Libraries and frameworks reach end of life. We have taken products through major runtime upgrades and framework end-of-life work. None of it adds a feature. All of it is real engineering, and skipping it is how products quietly rot.
The store is a moving target. The rules are published, but a change or a reviewer's interpretation often becomes real at the next submission, so a version that sailed through two months ago can fail today. We have had a user flow accepted across many submissions, then rejected because one path through it restricted access. We have seen a rejection over the privacy policy on the company's website, not the app itself. We have watched the same feature pass one review and fail the next because a different human looked at it. Each surprise means an unplanned conversation about budget and timeline, which is why our standing advice is simple: submit to the store long before you intend to launch. Rejections need runway.
The blame you absorb. Here is a cost no calculator includes. When any part of the system fails, the app gets blamed first. If a backend goes down, even one we did not build, the report still reads "the app is not working", and someone has to spend real hours proving where the fault actually is. Investigation that ends in nothing to fix is still spend. So is walking a first-time founder through their first store submission. And it is not only cost: it is relationship work, staying calm and professional with an unhappy customer while the evidence is gathered. Whatever support arrangement you set up, make sure it covers investigation, not just fixes.
The improvements you choose to fund. This one is not maintenance, but it usually shares the same team and budget, and in an active product it becomes the biggest regular line. That is good news. Change requests mean the product is alive and the people running it are paying attention. The improvements you discover after launch are worth more than most of the ones you specified before it.
Why the percentage rule misleads
Three reasons, and they compound.
The denominator lies. The rule quotes maintenance as a share of build cost, but two products built for the same price can have very different run costs. A low build price can mean a small, well-made product. It can also mean missing tests and corners cut, which is exactly what you pay for afterwards. A percentage cannot tell which one you bought.
Year one is not steady state. The early months are heavy with what real users find. The rhythm settles later. One number for both is a planning error in whichever direction you apply it.
It buries the real decision. Lumping in the features you choose to build with the software maintenance you must do hides the one call an owner actually has to make: how much learning and improving do we want to fund this year? That is a strategy question wearing a maintenance costume.
We have watched the cheap-build arc run its full course more than once. A product built under pressure, a warning given, a decision to keep patching. The patches never quite hold, the platform moves on, and eventually the app falls out of store support entirely and has to be rebuilt from scratch, at full price, on top of every patch that came before. These days we mostly decline the patching.
How support is actually bought
There is no single model, and the differences matter more than the headline number.
Some owners run pure time and materials: pay for what you use, when you use it. Others want a retainer, a guaranteed level of attention each month. What we see work again and again is a heavier retainer for the first 3 months after launch, when the real-user surprises land, tailing off to that steady 2 to 4 days per month.
Good retainers have a rhythm to them. Days not needed for fixes go on new features, which keeps the product moving. Some engagements carry a defect guarantee for the first stretch after delivery; it is worth asking any firm you talk to whether theirs does, and what it covers.
Some months the days go unused; others run over. If your agreement lets days carry over, the light months pay for the heavy ones. If it does not, the question lands on the table: fix only the urgent things and queue the rest, or find another way.
This is where the relationship earns its keep. Support is reciprocal: the owner needs the product earning so the vendor gets paid, and the vendor needs to know they will be paid so the work keeps moving. When something serious lands outside the agreement, the good outcome starts with a conversation, not a clause. Sometimes that is goodwill. Sometimes it is more this month and less next. In the best relationships it is the emergency fixed now and the money sorted after, because there is trust on both sides. Without that trust, every overage waits its turn in the paperwork, everything moves slowly, and the people who pay for the delay are the users and the owner's reputation. Ask any firm you talk to how they handle the months that run over. The answer tells you most of what you need to know.
One caveat that catches people out: scope. Support for the app is not support for the whole system. If different hands built the app, the backend and the web side, be precise about which parts your arrangement covers, because failures do not respect those boundaries, and someone has to hold the whole picture when things go wrong.
Release small, release often
One of the cheapest things you can change about your post-launch costs is the size of your releases.
Big releases can look efficient, but they create a larger surface for failure and a harder sign-off for whoever holds the budget. Small, frequent releases invert all of it. The budget ask is smaller, so approval comes easier. The change is smaller, so fewer things break, and when something does, you can ship again within days. Release, learn and react.
Teams coming out of research environments find this rhythm strange at first. Careful review habits run deep. Then they find it works, and the habit of shipping small becomes the habit of improving constantly. The companion essay covers the wider crossing from research team to product company.
The thing nobody budgets
After fourteen years of these conversations, we keep seeing the same pattern. Founders underestimate the build, and then they underestimate what comes after it by more.
So budget for the thing you cannot specify: the learning. Keep real money aside for the changes your customers will teach you to make, because they will not use the product the way you expect, and the fastest route through that is a modest launch, close observation and quick reaction, not a big bang.
And know that the bill is not only money. A team that can build a product still has to learn how to run one. Support needs people, feedback needs owners, releases need a rhythm, and somewhere along the way the organisation changes shape, from a team that built a thing into a company that runs one. The product going live is when your customers become your boss.
That transition is the real cost, and the real point. The money is just how you buy it.