How Much Does Software Maintenance Cost?

Software maintenance cost comes in two parts: engineering time, from $1,400 a month on our pricing, and the bills your software runs up by itself. Separating the two is the first step to a budget that holds. The bills barely move from month to month, while the engineering line grows when you ask for more and also absorbs work that Apple, Google and your dependencies put on the calendar whether you asked for it or not.

We are a senior engineering team in Ahmedabad. We build software for companies in the US, Britain and the GCC, and then we usually stay on to look after it. Every build we deliver through our custom software development work includes thirty days of support after launch, and most clients then keep a retainer, so the numbers below come from both sides of that conversation. If your product is a mobile app, our earlier post on what it costs to maintain a mobile app covers the app-specific side; this one covers the yearly bill for custom software in general.

Why the 15–20% rule is a guess

Search for software maintenance cost and almost every result says to budget 15–20% of the original build every year. We looked for where that number comes from and could not find a study behind it. It is a rule of thumb that has been repeated until it reads like data.

The research that does exist measures something different. In 2002 Robert Glass, in his book Facts and Fallacies of Software Engineering, put maintenance at between 40 and 80 percent of total software costs, and reported that enhancement accounts for roughly 60 percent of maintenance costs, against about 17 percent for fixing errors. That second figure matters more than the first. Most of what gets called maintenance is new work: a report someone asked for, a workflow that changed, an integration with a tool the business adopted last quarter.

So a percentage of the build tells you very little. On our card, a retainer at its floor is more than half of a $30,000 build every year, which no percentage rule would predict. At the other end, software that rarely changes may not need a retainer at all, and a product with an active owner can outspend its original build within two years simply because people use it.

What goes into a year’s software maintenance cost

Split the bill into what the software costs to keep alive and what people cost to keep it current. The first is mostly fixed. The second is the part you control.

The first three rows are bills. The last four are engineering hours, and they are where a budget either holds or doesn’t.

Platform deadlines you cannot skip

If your software includes a mobile app, two companies set part of your calendar. Since April 28, 2026, Apple requires every app uploaded to App Store Connect to come from Xcode 26 or later, compiled against the iOS 26 SDK, and Apple has raised this minimum most springs. From August 31, 2026, Google Play requires new apps and updates to target API level 36, which is Android 16, while apps already listed need to target API level 35 to stay available to new users on newer Android versions; Google says developers will be able to request an extension to November 1, 2026.

Neither deadline cares whether you planned a release that month. Missing one doesn’t stop the app working for people who already have it, but it blocks your next update, which is usually the urgent one, and on Google Play an outdated app also stops being offered to some new users.

Dependencies age whether you touch them or not

Modern software is mostly assembled from open-source components, and those components keep moving after your launch. Black Duck’s 2026 open source risk report, built on audits of 947 commercial codebases, found known vulnerabilities in 87% of them and high-risk ones in 78%, while 92% carried components at least four years out of date. None of that is a sign of a bad build; it is what happens to any codebase left alone for a few years. Frameworks also retire versions on published timetables; our US guide to custom software pricing sets out the support windows for Laravel, Node.js and PostgreSQL.

Regular small updates are cheap. A three-year jump across several major versions is a project of its own, and it usually lands when a security issue forces it.

Bugs and small changes

Inside the thirty days of support that follow a release, critical bugs are fixed in a median of 48 hours, with a regression test added so the same bug can’t return. After the first month, fixes and changes come out of whatever arrangement you choose: a retainer, a dedicated team, or ad hoc work from whoever is free.

A maintenance budget, line by line

Here is a first-year budget for a business web application with a companion mobile app. Two lines are our published prices or named fees; the hosting figure is an assumption to replace with your own provider’s estimate.

From year two the store line drops to $99, because Google’s fee is paid once. The engineering line is the one to size carefully. A retainer at our floor suits a live product that needs updates, monitoring and a steady stream of small changes; a product with an active roadmap outgrows it, and that is the point at which a dedicated engineer, at $3,200 a month for a mid-level developer on our card, starts to make more sense.

How to keep software maintenance cost down

Most of what makes maintenance expensive is decided long before anyone files a support ticket. These habits keep the engineering line small:

• Update dependencies a little every month. A minor version a month is an afternoon’s work. Four years of skipped releases is a migration.
• Keep the tests that catch regressions. Every fixed bug should leave a test behind, so the same fault can’t quietly return in the next release.
• Catch faults before users report them. Error tracking and uptime alerts show you on Friday what users would otherwise find on Monday.
• Write down why, not just what. A short note on each architectural decision saves the next engineer days of guessing, and those days are billable.
• Keep every account in your own name. Hosting, domains, developer accounts and service subscriptions you control can move with you if you change vendors.
• Read the monthly report. If the retainer report doesn’t show where the hours went, ask for one that does.

None of these is expensive on its own, and skipping them is how next year’s bill turns into a rebuild.

Retainer, pay as you go, or in-house

Three common arrangements:

Our retainers start from $1,400 a month, with agreed response windows rather than best effort, and unused hours roll one month forward. Pay-as-you-go looks cheapest until the first urgent fix, when the vendor has to relearn the code before touching it and you pay for that time too.

Signs your software maintenance cost is too high

A rising bill is not always bad news, since enhancements are maintenance too. What should worry you is a bill that rises while the output stays flat. The first sign is usually speed: each small change takes longer than the last one did, because the structure of the code is getting in the way. The second is repetition, where the same kind of bug keeps coming back because fixes went in without tests to hold them.

Two more are easy to spot from outside the code. If a framework or runtime is close to the end of its support, the upgrade gets dearer every month it waits. And if nobody can tell you what last month’s hours were spent on, the retainer is missing the monthly report it should come with.

When those signs pile up, it is worth asking whether rewriting the worst part of the system would be cheaper than patching it again and again. Sometimes it is, and a team that maintains software for a living should be willing to tell you so. To set the yearly bill against the price of the build itself, read our breakdown of what custom software development costs on average, which budgets the first year from the build side.