What Does Custom Software Maintenance Cost Per Year?

Introduction

The question of what custom software costs to build gets plenty of attention in quotes and board meetings. The question of what it costs to maintain gets far too little, even though it often weighs more heavily over the lifetime of a system than the initial build. Software is not a product you buy once and forget. It is more like a building: without maintenance the quality declines, even if you change nothing in the feature set.

In this article we give an honest picture of maintenance costs, without making the numbers prettier than they are. We write this from our practice at MG Software in Haarlem, where we both build new systems and maintain existing applications through fixed retainers. Want a first indication for your own situation? Our calculator gives a range, and below you can read where that range comes from and how to plan maintenance structurally.

Why maintenance is not an option but a given

Custom software never runs in isolation. It leans on dozens of external libraries, a database, a hosting environment, an operating system and often integrations with third-party systems. All of those parts keep moving. Security updates appear, frameworks release new versions, and vendor APIs change endpoints or retire old versions. Standing still does not exist, even if your functionality stays the same.

That aligns with how public-sector digitalisation is approached in the Netherlands: critical services must keep running reliably while the technology around them changes. The Digitale Overheid programme treats operations and further development as structural parts of digital services, not as one-off tasks after go-live. The same applies to your own business application: maintenance is the work that keeps your software moving with those changes, from dependency patches to following an updated accounting API.

The consequence of standing still is predictable. A payment integration that works today can stop in a year because the provider turns off an old API. A library with a known vulnerability stays in production because nobody has time to update. Maintenance prevents those surprises; it is not a luxury, but the baseline condition for operating safely.

The rule of thumb: 15 to 20 percent per year

"Software you do not maintain does not get cheaper. It slowly becomes less secure, and eventually unmaintainable."

— Jordan Munk, co-founder MG Software

The software industry often budgets 15 to 20 percent of the original build cost per year for maintenance. For an application that cost 50,000 euros, that lands at roughly 7,500 to 10,000 euros per year in development and upkeep, excluding hosting. That is not a law, but a useful starting point that matches what we see in practice with portals, dashboards and integrations.

At macro level, IT spend remains a structural line item. Gartner forecasts growing worldwide IT expenditure, with software and services forming a large share. That confirms what many custom software owners notice later: the one-off build cost is the beginning, not the total.

The rule of thumb is an average, not a guarantee. A simple internal tool with few integrations sits at the lower end. A platform with multiple integrations, many users and strict security requirements sits at the upper end, and sometimes above it in years when third parties make large changes. It helps to treat this as a fixed annual budget, not a surprise after the fact when the first major framework upgrade arrives.

What maintenance actually covers

Maintenance is more than occasionally fixing a bug. It covers security updates of dependencies, updating frameworks and libraries, moving along with vendor API changes, monitoring and alerting, backup checks, and resolving errors that surface in production. On top of that come small improvements that make daily use smoother, as long as they stay within the scope of "keeping it healthy".

Engineering teams at scale treat this as standard discipline. Stripe describes in Move fast without breaking things how automated tests, observability and controlled rollout make the difference between fast iteration and production incidents. An SME application does not need Stripe-level machinery, but the principles apply: dependency updates belong to a fixed rhythm, not to "when we have spare time".

A frequently forgotten line item is hosting costs and external services. An average business web application has monthly costs for hosting, a database, email delivery, error monitoring and analytics. Those costs are recurring and belong in your maintenance budget, not in the one-off build cost. Count them separately, so you do not assume that 15 percent "includes the server".

What drives the cost up or down

Three factors largely determine where you land in the range. First, the number of integrations: every external connection is a component that can change and therefore needs maintenance. A portal with only login and your own data is cheaper to run than a system that talks to Exact Online, a CRM, a payment provider and inventory software. Our pages on software integrations and the API integrations hub explain how those connections shape the maintenance profile.

Second, the health of the codebase. A system with good test coverage, clear documentation and a predictable deploy environment is cheaper to maintain than an opaque codebase where every change is nerve-racking. Invest in readable code and CI during the build; it pays back in lower maintenance hours.

Third, the age and choice of the stack. Software running on modern, widely supported technology is cheap to maintain for years. Software on outdated or niche technology gets steadily more expensive, because there are fewer developers and updates become harder. If your system is running into this, our page on modernising legacy software is relevant: sometimes phased redevelopment is cheaper than years of expensive emergency fixes.

Maintenance versus further development

It pays to distinguish maintenance from further development. Maintenance keeps the system healthy and secure: patches, monitoring, small fixes and keeping pace with external changes. Further development adds new functionality because your business grows or changes: an extra module, a new report, an extension of your customer portal. Both are valuable, but if you lump them together, something unfortunate happens: the moment there are no new features on the roadmap, maintenance stalls too.

That is why we often work with a maintenance retainer with a fixed number of hours per month for upkeep, and a separate budget for new functionality. That keeps the foundation healthy regardless of whether there are new requests that month. In quotes we separate those lines explicitly, so finance understands why "not building anything new for a while" does not mean the application needs no attention.

If you are building a product that keeps growing, also read how we design web applications with maintenance and further development in the same roadmap model. Architecture choices in week one determine whether year three maintenance stays predictable or explodes.

What happens if you do not maintain

Not maintaining feels like saving in the short term. In the medium term it is the opposite. Technical debt piles up, dependencies fall out of date, and at some point nobody dares make a change because the consequences are unpredictable. At the same time security risks grow: known vulnerabilities in old libraries are no longer patched, while attackers specifically hunt for them.

We recognise the pattern regularly in applications that went live quickly and then received "no budget for a while". The first signs are small: a slow deploy, a dependency that can no longer be updated without breaking, an integration that only works through manual workarounds. The endpoint is almost always the same: a rebuild that costs many times more than structural maintenance would have.

Skipping a few thousand euros per year sounds attractive, until three years later you face the choice of building everything again. Maintenance is therefore not a cost item, but insurance against a much larger expense. If you reach that point, our approach to software redevelopment covers phased modernisation without weeks of downtime.

Lessons from Haarlem: retainers in practice

At MG Software in Haarlem we maintain several custom portals and internal tools through fixed maintenance retainers. A typical example: a customer portal for a service provider in the Amsterdam region, connected to accounting and email, with dozens of active users each week. After go-live, maintenance in the first year ran at roughly 12 percent of the build cost. In year two that rose to 18 percent, not because the code was poor, but because an external API received a major upgrade and we tightened monitoring at the same time after a traffic spike.

What we take from that: a retainer of eight to twelve hours per month covers the baseline for many SME applications (dependency updates, monitoring, small fixes and a quarterly review). Peak years need a separate budget, for example when your framework gets a major release or when an integration with Exact or a payment provider changes. Clients who keep maintenance and further development separate have so far avoided unplanned downtime caused by outdated dependencies.

A retainer is not a 24/7 SLA for every client unless you explicitly agree that. It does mean someone looks at your system every month, that security updates do not sit idle for months, and that you have a fixed point of contact when something breaks. You notice that difference mainly at the moments when things do go wrong: a failed deploy, a webhook that stops firing, a certificate that expires.

How to plan a maintenance budget

Start with an inventory: which dependencies, integrations and environments does your application have? Note hosting, external APIs, the number of active users and whether the system is business-critical. Only then apply the 15 to 20 percent rule of thumb to the original build cost, and add hosting and SaaS services on top.

Ask your supplier explicitly how maintenance after delivery is arranged. Some agencies ship and disappear; others offer a retainer or a handover package with documentation and monitoring. Make sure dependency updates and security patches are in scope, not only "bug fixes when we have time".

Want to sanity-check your numbers? Use our calculator for a range based on scope and complexity, and book a short conversation if you already run software that could use a health check. Maintenance works best when it starts before go-live, not after the first outage.

Conclusion

Budget for maintenance from the start of every software project. A good rule of thumb is 15 to 20 percent of the build cost per year for upkeep and small improvements, with hosting and external services budgeted separately. Do not see it as an unpleasant surprise, but as the price of software that keeps running reliably and securely for years.

Want to know what maintaining your system realistically costs, or are you currently running software that could use some attention? Get in touch with MG Software. We look honestly at the state of your codebase and propose a maintenance plan or retainer that fits your budget and your integrations.