How Much Does Software Maintenance Cost? What to Budget After Launch

A commonly cited rule of thumb is that software maintenance costs roughly 15% to 25% of the original build cost per year. On a product that cost $150,000 to build, that works out to about $22,500 to $37,500 a year. It is a planning heuristic from industry practice, not a standard, and the real figure depends on how complex the product is, how many systems it connects to, how fast your users and requirements change, and how well the code was built in the first place. A small, stable internal tool can cost less. A fast-growing SaaS product or a regulated system can cost more.

The number itself matters less than knowing what it pays for and what makes it grow. This article breaks down what is in a maintenance bill, what pushes it up or down for different types of products, and how to budget for it before you launch.

What maintenance actually includes

Maintenance is not only fixing bugs. Most of the work falls into four groups.

Keeping it running. Hosting, databases, storage, backups, domain and certificate renewals, and the monitoring that tells you when something breaks. These costs are visible on invoices and usually grow with usage.

Fixing problems. Bugs that appear in production, performance issues as data grows, and the support work of diagnosing what a customer reported. Early after launch this is often the biggest share, because real users find things testing did not.

Keeping up with a changing world. Operating systems, browsers, frameworks, libraries, and third-party APIs all change. Security patches have to be applied. A payment provider updates its API, a framework version reaches end of support, a mobile platform releases a new major version. None of this adds a feature, but skipping it eventually breaks the product or exposes it to risk.

Small improvements. Tweaks based on user feedback, minor feature changes, and adjustments to business rules. Teams often count this as maintenance in practice, even though it sits between maintenance and new development. Decide up front how you will separate the two in your budget, because mixing them hides what the product really costs to keep alive.

What pushes the cost up or down

The rule of thumb is a midpoint. These factors move you above or below it.

• Code quality and tests. A codebase with automated tests and clear structure makes every change cheaper and safer. A codebase without them makes each change slower, because developers have to work out what else might break.
• Documentation and team continuity. If one person holds all the knowledge, any change in the team creates a cost to re-learn the system. Written setup instructions, architecture notes, and an owned repository reduce that.
• Number of integrations. Every external system you connect to is something that can change without warning. Products with many integrations spend more on adaptation.
• Usage and growth. More users and more data mean larger infrastructure bills and more performance work.
• Compliance and security requirements. Audits, access reviews, data retention, and logging add recurring work.
• Technology choices. Mainstream, well-supported stacks are cheaper to maintain than niche or abandoned ones. Our guide on choosing a tech stack for your MVP covers why boring choices pay off later.
• Release frequency. A product that ships improvements weekly needs more ongoing engineering than one that changes twice a year.

Maintenance by type of product

SaaS products. Infrastructure grows with customers, and you carry the operational load: uptime, backups, security, billing webhooks, and customer support. Multi-tenant products also need care when upgrading shared components. If you are budgeting for the build as well, see how much it costs to build a SaaS product.

Mobile apps. Apple and Google release new operating system versions regularly and update store requirements, so apps need periodic updates even when you add nothing new. You also test across devices and OS versions. The build-side budget is in how much mobile app development costs.

Internal business tools. Fewer users does not mean zero maintenance. The tools depend on the systems they connect to, such as accounting, CRM, or databases, and those systems change. Business rules also shift as the company does. See what a custom internal tool costs to build for the starting budget.

AI and LLM products. These have a few extra recurring items: model usage fees that scale with traffic, periodic migration when a model provider updates or retires a model, re-running evaluation sets after any change, updating the knowledge base the system draws on, and monitoring for quality drift. Our guides on reducing LLM API costs, monitoring production AI systems, and custom AI chatbot costs go deeper on this.

How to pay for maintenance

There are four common arrangements.

1. In-house engineers. Best when the product is central to your business and changes constantly. You carry the full cost of the people whether or not there is work.
2. Retainer with the team that built it. A recurring monthly fee for a block of capacity covering fixes, upgrades, and small changes. It keeps knowledge with people who know the code and gives you predictable cost.
3. Support contract with response times. Defines how quickly the vendor responds to issues of different severity. Useful when downtime is costly. Make sure it states what is included and what counts as new work.
4. Time and materials as needed. Flexible and cheap when little changes, but response can be slower and costs unpredictable. Our comparison of fixed-price and time and materials contracts explains the trade-offs of each model.

Whichever you choose, agree in writing on response times, what is included, how new feature requests are handled, and who has access to the code and hosting accounts.

How to keep maintenance cost down

You cannot eliminate maintenance, but decisions during the build change what it costs for years.

• Write automated tests for the critical paths. They make upgrades and fixes safer.
• Document how to run, deploy, and recover the system. Anyone competent should be able to take over.
• Own your accounts and repository. Hosting, domains, and source code should sit in accounts you control.
• Update dependencies regularly in small steps. Skipping upgrades for years turns them into expensive projects.
• Monitor from day one. Error tracking and uptime alerts find problems before customers report them, and cost less than investigating blind.
• Avoid unnecessary complexity. Every extra service, framework, and custom component is something to maintain. Build what the product needs now.
• Review third-party services periodically. Pricing, limits, and APIs change.

Warning signs that costs are climbing

• Small changes take much longer than they used to.
• Developers are afraid to deploy because something might break.
• Dependencies are several major versions out of date.
• Only one person understands how the system works.
• The same bugs keep returning.

When several of these appear together, you may be paying a growing tax on earlier shortcuts. At that point, it is worth deciding between continued patching and larger structural work. Our article on whether to rebuild or refactor your MVP lays out how to decide with evidence rather than frustration.

How to build a maintenance budget

1. Start from the build cost and apply a range, such as 15% to 25% per year, as a first approximation.
2. Replace the infrastructure estimate with real numbers. Get actual hosting and third-party service pricing for your expected usage, and add a margin for growth.
3. List recurring third-party fees, including licenses, APIs, email and SMS providers, monitoring tools, and app store accounts.
4. Reserve time for upgrades. Plan for at least one meaningful dependency or platform upgrade per year.
5. Set aside capacity for support and small changes, and decide who handles customer-reported issues.
6. Track actual spending for the first three months after launch, then adjust. Early costs usually run higher because of launch fixes, so do not extrapolate from the first weeks alone.

When you plan the original build, ask the vendor to include the maintenance estimate in the proposal. If you are still working out the build budget, our guide to MVP development costs is a good starting point.

Key takeaways

Plan for roughly 15% to 25% of the original build cost per year as a starting point, then refine it with real infrastructure quotes and your own usage. The bill covers running the system, fixing problems, keeping up with platform and dependency changes, and small improvements. Costs rise with integrations, growth, compliance needs, and weak code quality, and fall with tests, documentation, and simple architecture. Decide who maintains the product before launch, put the arrangement in writing, and track real costs early so your budget reflects reality.

If you want help estimating the full cost of ownership for a product you are planning, or taking over maintenance of an existing one, the RMJDG team can review your situation and suggest a realistic plan.