Custom software maintenance: what it covers and what it costs

“How much does it cost to maintain custom software after launch?” is the question almost no SME asks before signing, and the one that produces the most unexpected invoice twelve months in. At Evicron, an AI and custom software studio based in Barcelona, we see the same pattern on every project: whoever only budgets for the initial build ends up facing a maintenance line item they didn’t plan for a year later. This guide covers what that maintenance actually includes, what it tends to cost, and what to ask before signing.

What custom software maintenance actually covers

“Maintenance” isn’t one single thing, and it’s worth separating what’s included from what isn’t before agreeing to a contract:

• Bug fixes: issues that surface in production and weren’t caught during initial testing.
• Security and dependency updates: libraries, frameworks and operating systems that need patching to avoid exposure.
• Monitoring and uptime: keeping an eye on whether the system is still running, with alerts if it goes down.
• Small tweaks and adjustments: minor changes to what already exists (a new filter, an extra report) that aren’t a new project but aren’t free either.
• Incident support: someone who answers when a user reports a problem.

What usually falls outside standard maintenance is any sizeable new feature: that’s scope for a new piece of work, billed separately, and the contract should say so explicitly to avoid disputes later.

How much it costs: the 15-25% annual rule

There’s no flat rate that works for every system, but there is a well-established market reference: annual software maintenance typically runs between 15% and 25% of the original development cost, according to Edana’s analysis of total cost of ownership. Applied to the indicative ranges we work with at Evicron — a custom SaaS product from €12,000, or an applied AI project from €6,000 — that means budgeting upfront for somewhere between €900 and €3,000 a year just to keep what already exists running, before planning any improvements.

That figure moves up or down depending on three factors: how many external systems the software integrates with (each integration is one more point that can break when the other system changes), how critical it is to day-to-day operations (a system that handles invoicing or payroll needs a faster response than an internal lookup panel), and how mature the technical foundation it was built on is. A project carrying accumulated technical debt — legacy code, outdated dependencies — can end up costing far more than that starting 25%.

Who should handle it: the agency that built it, or your own team?

This is where something we already covered when discussing who owns your custom software’s code comes into play: if the contract was closed without lock-in, as we work at Evicron, the client owns the final code from day one and can decide who maintains it. That opens three reasonable paths:

1. Maintenance with the same provider: the fastest option, since they already know the system inside out.
2. Maintenance with an in-house team: makes sense when the company already has, or is building, technical capacity of its own and the software is central to the business.
3. Switching provider: only viable without migration cost if the code is genuinely portable — one more reason never to accept a contract with hidden dependencies or restricted access to the repository.

Custom software delivered badly, with the code locked behind the original provider, turns this decision into an illusion: in practice there’s only one path, and it’s the most expensive one long-term.

What to ask before signing a maintenance contract

Before accepting any maintenance proposal, it’s worth getting a concrete answer to these questions:

• What response time does the contract guarantee for a critical incident (hours, days)?
• Is the price a fixed monthly fee, a block of hours, or billed per resolved incident?
• What counts as an “included minor tweak” versus a “new feature billed separately”?
• Who has access to the code, the server and the credentials for the duration of the contract?
• What happens if I decide to switch maintenance provider later on?

At Evicron we respond to incidents in under 24 hours, precisely because the software we build stays the client’s and our relationship with them doesn’t depend on locking them into a contract.

When it’s worth moving from ad-hoc support to an ongoing contract

If the software barely changes and the company just needs it to keep running, an occasional block of hours is usually enough. But as soon as the system starts evolving — new integrations, more users, regulatory changes that force an adjustment — an ongoing maintenance contract with an agreed response time ends up cheaper than firefighting case by case, because it skips the queue of a provider that prioritises contracted clients over whoever calls only when something breaks.

Want a realistic maintenance budget for your custom software project? Get in touch: the first consultation is free and we reply within 24 hours.