Software Maintenance Cost: What to Budget Every Year After Launch
Software maintenance cost explained: the 15–25% rule of thumb, what drives the annual bill, realistic ranges, and how to keep it from eating your roadmap.
Written by Ing. Hlib Yarovyi, Founder
Plan to spend roughly 15–25% of the original development cost on software maintenance every year. A product that cost $100k to build typically needs about $15k–25k a year in engineering just to stay secure, compatible and working, before you add a single new feature, and before hosting and third-party bills. Older systems, products with many integrations and code without tests sit at the top of that range or above it.
That number surprises people who think of software as a one-off purchase. It is closer to a building: the construction is a one-off, the roof, heating and repairs are not. This guide explains where maintenance money goes, what pushes the annual bill up or down, and how to budget for it without letting it swallow your roadmap.
Where the 15–25% rule comes from
The figure is a rule of thumb, not a law. It appears across vendor pricing guides and total-cost-of-ownership studies, and analysts such as Gartner have long argued that most of a system’s lifetime cost arrives after launch, not before. In practice, the percentage we see falls in a band:
| Situation | Typical annual maintenance | Why |
|---|---|---|
| New product, modern stack, good tests | 10–15% of build cost | Few surprises, updates are small and safe |
| Typical business application | 15–25% | Regular updates, some integrations, occasional bugs |
| Many integrations or regulated data | 20–30% | External APIs change, compliance work recurs |
| Legacy system, no tests, old framework | 25–40%+ | Every change is slow and risky |
Treat these as approximate ranges for planning. Your real number depends on the factors below, and it should be estimated from the code, not from a percentage.
The four kinds of maintenance work
Maintenance is not just bug fixing. Software engineering textbooks split it into four types, and all four show up on a real invoice.
Corrective: fixing what is broken
Bugs reported by users, errors found in monitoring, data that ends up in a bad state. This is what most people imagine maintenance is, and on a healthy product it is often the smallest share.
Adaptive: keeping up with a changing world
The software did not change, but everything around it did. Browsers update, iOS and Android release new versions every year, payment providers deprecate API versions, cloud providers retire runtimes, and regulations change. Mobile apps feel this most: the app stores require builds against recent SDKs, so an untouched app eventually cannot be updated at all. If you run apps, see what that involves in mobile app development.
Perfective: small improvements
Users ask for a filter, an export, a clearer error message. Each is small. Together they are a steady stream that keeps the product useful. Draw the line between this and new features explicitly in your budget, or “maintenance” becomes a quiet second roadmap.
Preventive: paying down risk
Dependency updates, security patches, test coverage, removing dead code, upgrading the framework before it reaches end of life. This is the work everyone skips first and regrets most. We cover how unpaid technical debt shows up in a separate post on the signs of technical debt.
What actually drives the annual bill
Two products with the same build cost can have very different maintenance costs. The biggest drivers:
- Number of integrations. Every external API is a dependency you do not control. Payment, CRM, ERP, shipping, SSO and AI providers all change on their own schedule.
- Test coverage. Without automated tests, every update needs manual checking, so updates get postponed, so they pile up.
- Age and popularity of the stack. Mainstream frameworks get security fixes and well-documented upgrade paths. Abandoned libraries do not.
- Infrastructure model. Self-managed servers need patching, backups and monitoring. Managed services shift much of that to the provider, for a higher hosting bill and a lower engineering one. Our DevOps services page goes into that trade-off.
- Platforms. A web app plus an iOS app plus an Android app is three things to keep current.
- Compliance. Health, finance and children’s data bring recurring audits, access reviews and documentation.
- Usage growth. More users find more edge cases and push the database harder.
Running costs that are not engineering
Maintenance quotes usually cover people. The product also has bills of its own, and they belong in the same budget:
| Cost | Typical range (approximate) | Note |
|---|---|---|
| Cloud hosting and database | From tens to thousands of dollars a month | Scales with users and data |
| Monitoring and error tracking | Free tiers to a few hundred a month | Worth it from day one |
| Email, SMS and push | Usage-based | SMS gets expensive in volume |
| Third-party APIs and SaaS | Varies widely | Maps, search, AI models, analytics |
| App store fees | About $99/year Apple, one-off $25 Google | Plus commission on in-app sales |
| Domains, certificates, backups | Small | Easy to forget, painful to lose |
| Licences | Varies | Paid UI kits, fonts, SDKs, editors |
For AI features, model usage can become the largest line on its own. Budget it per user or per request, not as a fixed number.
A worked example
Illustrative example with stated assumptions: a B2B web application that cost $120k to build, with a customer portal, an admin panel, Stripe payments and an ERP integration, on a managed cloud.
| Line | Assumption | Yearly cost |
|---|---|---|
| Engineering maintenance | 18% of build cost | ~$21,600 |
| Hosting, database, backups | Managed services, moderate traffic | ~$4,800 |
| Monitoring, email, third-party APIs | Usage-based | ~$2,400 |
| Total running cost | ~$28,800 a year |
Then add new features on top, which most products need to stay competitive. Many teams end up spending as much or more on improvements as on pure maintenance. To see what new work itself tends to cost, our custom software development cost guide and web app development cost guide show market ranges.
How to pay for maintenance
There are three common models, and each fits a different kind of work.
Monthly retainer. A fixed monthly fee for a defined scope: dependency updates, monitoring, security patches and a number of support hours. Predictable, good for routine work. Make sure the contract says what happens with unused hours and how urgent issues are handled.
Fixed-price projects for big upgrades. A framework upgrade, a database migration or a move to a new cloud is a defined piece of work and can be quoted as one. That keeps large jumps out of the monthly budget. If you are moving infrastructure, see cloud migration.
An embedded engineer or small team. When maintenance and new features run together, a part-time or full-time engineer who knows the code is often cheaper than paying a vendor to re-learn it every time. That is the logic behind staff augmentation: monthly terms, the same people, no re-onboarding.
Avoid open-ended hourly billing with no scope at all. It makes the yearly number impossible to plan and gives nobody an incentive to make maintenance cheaper.
How to make maintenance cheaper
The cheapest maintenance is designed in, but most of these work on existing products too:
- Update in small steps. Monthly dependency updates are boring. A two-year catch-up is a project.
- Test the paths that make money. Sign-up, checkout, the core workflow. Automated tests make every update safer and faster.
- Prefer managed services. Let the cloud provider patch the database and the operating system.
- Automate deployment. If releasing is one click and reversible, small fixes ship the same day instead of waiting for a “release window”.
- Watch errors, not complaints. Error tracking finds problems before customers do, when they are cheaper to fix.
- Delete features nobody uses. Every feature has a maintenance cost forever. Check usage and remove the dead ones.
- Keep accounts and documentation in your name. Switching maintainers is cheap only if the next team can build and deploy from your documentation.
When maintenance costs too much
Sometimes the honest answer is that the yearly bill is high because the code is in poor shape. Signs: every small change takes days, fixes create new bugs, and nobody wants to touch certain parts. At that point, paying for maintenance is paying interest on a debt. A focused audit tells you whether to refactor gradually, fix specific hot spots, or replace a component. Our code audit gives you that verdict in writing.
And if the product was handed to you by a vendor who is gone, start with the checklist in how to take over a software project.
The short version
- Budget about 15–25% of the build cost per year for engineering maintenance.
- Add hosting, monitoring, third-party APIs and app store fees on top.
- Integrations, missing tests and old stacks push the number up.
- Use a retainer for routine work and fixed-price projects for big upgrades.
- Small, regular updates are always cheaper than a big catch-up.
FAQ
How much does software maintenance cost per year?
A common rule of thumb is 15–25% of the original development cost per year, and industry sources such as Gartner-style TCO studies often cite maintenance as the majority of lifetime software cost. A product that cost $100k to build therefore typically needs roughly $15k–25k a year, before new features and infrastructure. Old, untested or heavily integrated systems sit above that range.
What is included in software maintenance?
Four kinds of work. Corrective maintenance fixes bugs. Adaptive maintenance keeps the software working as browsers, operating systems, APIs and regulations change. Perfective maintenance makes small improvements users ask for. Preventive maintenance pays down technical debt, updates dependencies and improves tests before something breaks.
Are hosting and licences part of maintenance cost?
They are part of the running cost, but most quotes list them separately. Budget for cloud hosting, databases, monitoring, email and SMS, third-party APIs, app store fees and paid licences on top of engineering time. For AI products, model usage can be the largest single line.
Can I skip maintenance for a while to save money?
You can, but the bill does not disappear, it grows. Unpatched dependencies collect security vulnerabilities, frameworks reach end of life, and integrations break when a provider changes its API. Catching up after two years usually costs more than steady small updates would have.
Should maintenance be fixed-price or hourly?
Routine maintenance suits a monthly retainer with a defined scope, such as updates, monitoring and a number of support hours. Larger upgrades, such as a framework migration, are better quoted as separate fixed projects. Pure hourly billing for everything makes the yearly cost hard to predict.
How do I lower software maintenance costs?
Keep dependencies current in small steps, add automated tests to critical paths, use managed services instead of self-run servers, document deployment, and remove features nobody uses. The cheapest code to maintain is the code you deleted.