Custom software maintenance cost is a line many proposals leave out, and owners tend to discover it the hard way. Software is not a finished object. It runs on servers, libraries and platforms that other people keep changing, and it needs someone paying attention for as long as it runs.
The good news is that maintenance is not mysterious. It breaks into a handful of recurring jobs, each of which you can ask a developer to price in writing. The bad news is that no honest article can give you one number, because the right figure depends on how complex the system is, how much it connects to, and how much the world around it changes.
This guide lays out what you are paying for, the one common rule of thumb and why to treat it carefully, and how to budget without guessing. If you are still deciding whether to build, our guide to custom software for small business covers the running cost as part of the decision.
Want maintenance priced into the plan? Request an estimate and we will reply with scope and a price range for a sensible first phase.
Four kinds of maintenance
Software engineers have long sorted maintenance into categories. The ISO/IEC 14764 standard, summarized on Wikipedia's software maintenance page, names four:
- Corrective: fixing bugs or failures to meet requirements.
- Adaptive: changing the software so it keeps working as its environment changes, such as a new operating system, browser or payment provider requirement.
- Perfective: improving qualities like user experience, performance and maintainability.
- Preventive: changes made ahead of time to avoid future problems.
The software consultancy Edana makes the same point in plainer terms: maintenance is not limited to bug fixes, and it covers fixing production issues, adjusting to technical or regulatory change, and adding features or improving the experience. Each behaves differently on the budget. Fixes are unpredictable, adaptive work follows other companies' calendars, and new features are optional and entirely in your control.
The recurring line items
1. Hosting and infrastructure
Servers, databases, storage, backups, monitoring and email delivery all bill monthly. A single small server can be inexpensive, but real systems add a database, backups, a domain, transactional email and monitoring, each with its own charge, and traffic spikes can change the bill. Ask for the estimate by service, and make sure the account is in your name so you can see every charge.
2. Security patches
The 2021 edition of the OWASP Top 10 lists vulnerable and outdated components as a category of risk. It says you are likely exposed if you do not know the versions of all the components you use, if software is unsupported or out of date, if you do not scan regularly, or if you do not fix and upgrade components in a risk-based, timely way. It notes that the last problem is common where patching is a monthly or quarterly task, which leaves days or months of exposure to vulnerabilities that already have fixes. It recommends a patch management process, continuous inventory of components, monitoring of vulnerability databases, and an ongoing plan for monitoring, triaging and applying updates for the lifetime of the application. That plan is a recurring cost, however small.
3. Dependency and platform upgrades
Your system is built on a language runtime, a framework and many libraries, and each has its own end-of-life date. Two examples:
- The official Node.js release page advises that production applications should only use Active LTS or Maintenance LTS releases, and describes long-term support as typically guaranteeing critical fixes for a total of 30 months. A system left alone eventually sits on an unsupported runtime.
- The PHP project's supported versions page, as of October 2026, lists security support for PHP 8.2 ending December 31, 2026, and for PHP 8.3 ending December 31, 2027. Branches older than 8.2 no longer appear there and get no fixes at all.
Tools can take part of the load. GitHub's Dependabot security updates raise pull requests that update a vulnerable dependency to the minimum version that includes the patch. A person still has to review, test and deploy them, and a major version jump usually needs real work.
4. Support and fixes
Someone has to answer “it's not working” and find out why. This is the line most people forget. Decide what response you need: a church admin with a weekly sign-up form needs less than a festival registering vendors the month before opening day. Support terms, such as who answers, how you report problems and what is included, belong in writing.
5. Small changes
Real use produces requests: a new field, a changed report, a different email. Budget a block of hours or a monthly allowance for these, and keep larger additions as separate, scoped projects.
The rule of thumb, and how far to trust it
Edana describes a common rule that annual maintenance costs run 15–25% of the initial development cost. The article calls it a starting point, adjustable for how critical the software is, how fast its technologies are changing, how much is open source, and how demanding the support terms are. It adds that a project with high technical debt may need an extra 10–20% provision, and gives the example of a Swiss industrial SME that budgeted a flat 20% and had to raise it to 35% the following year. It cites no study for the rule.
So treat 15–25% as a planning prompt, not a fact. It is a useful sanity check: if a proposal implies maintenance far below it, ask what is not included. It is a poor substitute for a line-item estimate from the people who will do the work.
To see how the build side is priced, read our guide to what custom software development costs.
How to budget without guessing
- Ask for maintenance as a separate, itemized quote alongside the build: hosting, monitoring, patching, support, and a change allowance.
- Put the infrastructure in your name so hosting costs are visible to you.
- Know your seasonal peaks. A registration system, ticketing flow or donation page needs the most attention right when it is busiest.
- Keep the system simple. Every dependency is something to upgrade later. Fewer moving parts is the cheapest maintenance strategy.
- Insist on documentation so a second developer could take over. Undocumented systems cost more to maintain because every change begins with archaeology.
- Name an internal owner who notices when something stops working. Silent failures cost more than loud ones.
Comparing against a subscription
A fair comparison with an off-the-shelf product counts both sides over several years. A subscription bundles hosting, patching and support into the seat price; a custom build unbundles them and you pay for each. That can still favor custom work in the right situation, but only if you price the running costs honestly. Our piece on readiness for custom software includes naming the owner who keeps it healthy.
The honest verdict
Choose a subscription product if you do not want to think about patches, runtimes or who answers the phone. You are paying for exactly that, and for most standard needs it is a good deal.
Build custom only if you will budget for ongoing care as a normal annual cost, name an owner, and keep the accounts and code in your hands. Get maintenance quoted in line items, use 15–25% only as a sanity check, and be wary of any proposal that does not mention it.
We quote the running cost alongside the build and keep code and cloud accounts in your name. Learn more on our custom software for small business page, or ask for the numbers below.
Frequently Asked Questions
How much does custom software maintenance cost per year?
It depends on complexity, integrations and how critical the system is, so any single figure is a guess. One common rule of thumb, described by the consultancy Edana without a cited study, puts annual maintenance at 15 to 25 percent of the original build cost. Use that only as a sanity check. A better approach is an itemized quote covering hosting, security patches, dependency upgrades, support and a change allowance.
What does software maintenance include?
It includes fixing bugs, adapting to changes in browsers, operating systems and third-party services, improving performance and usability, and preventive work that avoids future problems. In practice it shows up as hosting bills, security patching, upgrading libraries and runtimes before they reach end of life, answering support requests, and small requested changes. New major features are usually better scoped and priced as separate projects.
What happens if I do not maintain custom software?
It keeps running until something around it changes. Runtimes and frameworks reach end of life and stop receiving security fixes, known vulnerabilities in libraries go unpatched, and third-party services change their requirements. Failures can be silent, so problems may go unnoticed. Fixing a neglected system often costs more than steady upkeep, because several overdue upgrades have to be done together.
Is custom software maintenance more expensive than a SaaS subscription?
Not necessarily, but the costs are laid out differently. A subscription bundles hosting, patching and support into a per-seat price that grows with headcount. Custom software unbundles those costs, so you pay for each, though you are not paying per user. Compare both over three to five years, include staff time and the cost of changes, and ask for maintenance to be quoted in line items before you decide.