What app maintenance actually costs per year

Two lines, and most budgets only have one of them. Keeping a $39,000 – $60,000 app working costs $7,500 – $10,000 a year. Changing it costs more: two ordinary features people ask for once they're using the thing come to $13,000 – $19,000, which is about 32% of what the app cost to build.

$7,500 – $10,000: Keeping it working. A planning convention, applied to the $39,000 – $60,000 build below
$13,000 – $19,000: Two features people ask for in the first year
$10,000 – $15,000: The cheapest change project on an app that ships to both stores

Written by

WhatWillMyAppCost

We build the estimator this site runs on, and we design and build custom mobile and web software for a living. Every figure below is the estimator’s own output, except the published vendor prices, which are read off each company’s own page and dated.

Your app shipped, people are using it, and somebody wants to know what it costs to keep. The figure you'll find everywhere is 15 to 20 percent of the build per year. That number is real, and it covers less than most people think it does.

What the year splits into, why the cheapest change project is $10,000 – $15,000, what the same two features cost during the build against a year later, the one scheduling decision that takes $13,000 off, what happens to an app nobody touches, and whether the team that built it should keep it.

How much does it cost to maintain an app per year?

Budget two lines. On the $39,000 – $60,000 app priced here, keeping it working is $7,500 – $10,000 a year, and that's the 15 to 20 percent figure everybody quotes. Changing it is separate, and for most apps in real use it's the larger of the two.

Keeping it working: $7,500 – $10,000 a year. Store accounts, hosting, the services the app leans on, and the engineering to survive each year's iOS and Android releases. What an app costs to build has the convention this comes from. Nothing new appears on any screen for it.
Changing it: $13,000 – $19,000 for two features. This is the line people leave out, and it's the one that produces the awkward conversation in month eight when somebody asks why adding a search box is a project.

The two together come to $20,000 – $29,000 for a first year where the app both stays up and grows a little. Against the middle of a $39,000 – $60,000 build, that's about half again in the first twelve months. Price the build itself and the year after is easier to size.

Why is a small change never small?

Because the cheapest thing this estimator prices for an app already in both stores is $10,000 – $15,000, and that's a project with no feature in it at all. On one store instead of two it's $9,000 – $14,000. The floor isn't the feature. It's everything wrapped around the feature.

Somebody works out what you actually want, which is rarely what the one-line request said.
It gets drawn, because a new screen in an app that already has forty of them has to look like it belongs.
It gets built, and it gets built against a codebase somebody has to read first.
It gets tested on real devices, including the ones your users have and nobody in the office does.
It goes through App Store and Play review, which takes as long as it takes.

Only the middle one scales with how big the feature is. Search on its own comes to $12,000 – $17,000. Documents the app emails out come to $12,000 – $17,000, the same band, and they are not the same amount of engineering. That tells you where the money is going.

Why does the same feature cost more after launch?

Because afterward it pays for a release of its own. Search and emailed documents added $3,000 to this app when they were part of the original scope. The same two, commissioned a year later, come to $13,000 – $19,000, and almost none of that difference is the features.

$3,000: Both features, included in the original build
$13,000 – $19,000: The same two, commissioned a year later
$3,500: The feature work inside that later figure. The rest is the release

Search and emailed documents cost $3,000 inside the build and $13,000 – $19,000 a year after it. The engineering barely moved: $3,500 of that later figure is the features themselves. The rest is a release that now belongs to them alone, instead of one they shared with everything else being built.

That's the argument for spending longer on scope before the build starts. It's also why "we'll add that in phase two" costs more than it sounds like: you aren't deferring the feature, you're buying it a release of its own. Choosing a first version is the same decision from the other end, and the things worth postponing are the ones you'd have to rebuild anyway once real people had used the app.

How do you make the year cost less?

Ask for things in groups. Those two features commissioned separately come to about $29,000. Asked for together, as one release, about $16,000. The difference is $13,000, and you get it for keeping a list instead of sending an email each time somebody has an idea.

One thing at a time, as it comes up: About $29,000 for the two. Each one carries its own discovery, its own testing and its own release, and you pay for that twice.
A list, released together: About $16,000. One pass through everything that isn't the feature itself, and one trip through store review for both.

Two or three releases a year suits most businesses this size. It gives you long enough to find out what people actually want, and it stops the wrapper costs repeating. The other half of it is writing requests down as they arrive instead of relying on remembering them, because a list assembled in one sitting the week before a release is a list of whatever happened recently.

What happens to an app nobody maintains?

It keeps working, then it stops, and the stopping is sudden. Apple and Google both ship a major OS release every year, and both eventually require apps on their stores to be built against a reasonably recent version. Neither of those is a bug in your app. Both of them break it.

The pattern is consistent enough to plan around. An app left alone drifts quietly for a year, then a phone updates and something visible goes wrong, and the fix is no longer a fix: it's an upgrade of everything the app is built on, done all at once, under time pressure, by somebody reading the code cold. The bill for that arrives as one number and it's larger than the $7,500 – $10,000 would have been.

If money is genuinely tight, the line to protect is the keep-it-working one. A year with no new features and a current build is fine. A year with new features on a foundation nobody has touched is how you end up unable to ship the bug fix. What it costs to keep online covers the smaller half of that bill, which surprises people in the other direction.

Who should do the maintenance?

Whoever built it, if they're still around and you were happy with them. The reason is cost rather than loyalty: a team that already knows the codebase skips the reading-it-cold step, and that step is a real part of every figure on this page.

The team that built it: Cheapest per change, because the discovery half of each request is shorter. Worth agreeing a rough plan for the year at the end of the build, while everybody still has the project in their heads.
Somebody new: Expect the first change to cost more than the ones after it. Somebody has to read the whole thing before they can safely touch any of it, and that is a real piece of work that only happens once.

Either way, the thing worth having is a written record of what runs where and what it depends on. It costs almost nothing to produce at the end of a build and it is expensive to reconstruct two years later.

Maintenance is two budgets. Keeping a $39,000 – $60,000 app working is $7,500 – $10,000 a year and buys you nothing new. Changing it is $13,000 – $19,000 for two features, because the cheapest change project is $10,000 – $15,000 whatever the feature turns out to be.

So decide scope hard before the build, when the same two features cost $3,000, and ask for things in groups afterward, which is worth $13,000 on these two alone. Then protect the keep-it-working line even in a year when you add nothing.

FAQ

Questions about the year after launch

Is 15 to 20 percent of build cost per year accurate for app maintenance?

For keeping it working, yes, and that's what the figure means. On the $39,000 – $60,000 app priced here it comes to $7,500 – $10,000 a year, covering store accounts, hosting, third-party services and the engineering to survive annual OS releases. It does not cover new features. Two of those come to $13,000 – $19,000 on the same app, about 32% of the build, so a budget that uses the percentage and expects changes inside it is short by roughly twice what it set aside.

How much does it cost to add a feature to an existing app?

More than the feature. The cheapest change project this estimator prices for an app in both stores is $10,000 – $15,000 before any feature is named, and $9,000 – $14,000 if you only ship to one. Search comes to $12,000 – $17,000 and generated documents to $12,000 – $17,000, the same band, for work that is not the same size. Discovery, a design pass, testing on real devices and store review are the same work whatever you asked for.

Does a change to the backend still need App Store review?

Only if the app itself changed. Work that lives entirely on the server, a report, a pricing rule, a new field the app already knows how to display, ships when you're ready and answers to nobody. Anything that changes what's installed on the phone joins the review queue. That's worth knowing when you plan a release, because it means two changes of similar size can have very different dates, and it's one of the few levers on the calendar you actually control.

Is it cheaper to include a feature in the original build?

Much, though not for the reason people assume. Search and emailed documents added $3,000 to this app inside the original scope and come to $13,000 – $19,000 commissioned a year later. The engineering is nearly the same both times: $3,500 of the later figure is the features. What you're paying for is a release of their own, where the build gave them one they shared with everything else.

How often should an app be updated after launch?

Often enough that people believe requests go somewhere, rarely enough that you aren't buying a release for each one. For most businesses this size that lands at two or three a year. The cost of getting it wrong is visible: the two features here run about $29,000 one at a time against $16,000 together. What matters more than the cadence is writing requests down as they arrive, because a list assembled the week before a release is a list of whatever happened recently.

What happens if an app is not maintained for two years?

It usually still runs and it usually cannot be updated. Apple and Google both ship a major OS release every year and both require store submissions to target a reasonably recent version, so a codebase left alone accumulates an upgrade it has to do all at once before it can ship anything, including a one-line bug fix. That work arrives as a single bill under time pressure, which is the expensive way to buy it.

Does app maintenance include hosting?

It's usually quoted inside the same percentage, and it's the small part of it. Hosting, the store accounts and error monitoring for a small business app run in the region of $57 a month, so the great majority of a maintenance figure is engineering time rather than infrastructure. What it costs to keep an app online breaks the bill out.

Should the company that built the app also maintain it?

Usually, and the reason is narrower than loyalty. Reading a codebase well enough to change it safely is a real piece of work, it happens once, and whoever does it puts it on their first invoice. That’s the whole of the premium for moving, so if the relationship isn’t working, move: you pay the reading once and then you’re level. What makes the move cheap is a written record of what runs where, which costs almost nothing at the end of a build and is expensive to reconstruct two years later.