The project closed in March. The application runs, people use it, and the team that built it has moved on to other work. In September the CFO asks the CTO for next year’s budget and poses a question nobody prepared for: what does it cost to keep this system running? Two proposals sit on the desk. One vendor offers a fixed monthly retainer with an SLA; the other offers a block of hours billed as used. The totals differ by half, and neither document makes clear what exactly you are paying for.
This is a common situation, because maintenance is the least visible part of an application’s life. The build is planned for months, while maintenance is often added to the contract in the last week before go-live. Yet maintenance accounts for most of what software costs over its lifetime, and a badly shaped contract can cost more than the support itself: in downtime, in escalations and in features nobody has time to deliver.
This article is for a CTO deciding on a maintenance model and budget. It covers what the cost is made of, how L1–L3 support levels differ, how to build the annual budget bottom-up instead of guessing a percentage, and what an SLA has to contain to be useful in practice. We made the general case for why maintenance matters as much as development in an earlier piece on post-implementation support strategies. Here we deal with money and the contract.
What is the cost of maintaining an application after launch made of?
“Maintenance” covers several different kinds of work, and vendor proposals often lump them into one line. ISO/IEC/IEEE 14764, the standard for the software maintenance process, distinguishes four types (summarised in the maintenance chapter of the SWEBOK guide): corrective, fixing reported defects; preventive, removing latent faults before they surface; adaptive, keeping up with changes in the environment such as new operating system, browser, library or partner API versions; and perfective, improvements and small functional changes.
The distinction maps straight onto the budget. Corrective work depends on the quality of the system and is hard to predict. Adaptive work is unavoidable and grows with the number of dependencies: every library and every integration eventually needs updating. Perfective work is, in practice, continued product development, and it is usually what eats the maintenance budget, because the business always has another request.
Robert L. Glass summarised the research in two statements in Facts and Fallacies of Software Engineering (2002): maintenance typically consumes 40 to 80 percent of software costs, and enhancements make up roughly 60 percent of maintenance costs, rather than bug fixing. These figures are more than two decades old and should not be read as a price list, but the message still holds: most of the money spent on maintenance goes on changes the business wants, not on patching.
Then there are costs that are not people’s time: hosting and cloud, software and tooling licences, monitoring, backups, certificates and third-party services. They are usually absent from maintenance proposals because the system owner pays for them, but they belong in the annual budget.
The first practical takeaway: before you compare proposals, split each into four lines. Readiness and incident response, defect fixing, technical updates and functional changes. Two proposals that blend these into one figure in different proportions cannot be compared.
What does maintenance cost per year, and why is a percentage of build cost only a starting point?
The most common answer to the maintenance budget question is “take a percentage of the build cost per year”. The figures quoted in industry articles vary widely, and we have not found a credible, current study that establishes any specific figure as a market norm, so treat such a percentage purely as an estimate for a first conversation with the board, not as the basis for a budget.
A percentage of build cost has three weaknesses. First, build cost is a poor predictor of maintenance cost: two applications with the same price tag can have very different numbers of integrations, users and availability requirements. Second, it ignores quality: a system with no tests and a lot of technical debt generates more corrective maintenance than a well-built system of the same price. Third, it says nothing about how many functional changes the business wants, and those usually decide the figure.
What actually moves the cost up or down? The number and stability of integrations with external systems, the required support hours (business days or around the clock), how critical the system is to the business, the number of users and environments, the age of the technology and the pace of dependency updates, the quality of automated tests and monitoring, and whether the maintenance team is the same team that built the system. The table later in this article sets these factors out in detail.
That is why a bottom-up budget, built from hours and roles, is the better method; we show it in a separate section. Work out the percentage only at the end, as a sanity check: if you arrive at a few percent of build cost for a critical system with many integrations, you have probably missed something.
How do L1, L2 and L3 support levels differ?
Splitting support into levels comes from IT service management practice, and its purpose is to stop expensive developer hours being spent on issues someone else can resolve. Each level has a different cost and different skills.
L1, first line. Takes tickets, logs them, sets the priority and resolves simple issues from a script: password resets, permission problems, questions about how a feature works. Everything else is passed on with complete information. L1 is often run in-house, because your own people know the users and their processes, or outsourced to a specialist service desk.
L2, application support. Diagnoses problems in the running system: analyses logs, data and configuration, reproduces defects, handles known errors and their workarounds, performs data fixes and administrative tasks. L2 needs to know the application well but does not always change code.
L3, engineering support. Developers who know the code and architecture fix defects in the software, prepare patches, deploy them and analyse the root causes of incidents. It is the most expensive level and the one whose quality most affects whether the same problems keep coming back.
What matters most in the contract is not the naming but the boundaries between levels. Write down who runs each one (your company, the vendor, an external service desk), what information a ticket must contain when it is escalated (steps to reproduce, a screenshot, the user ID, the time it happened) and how quickly the next level picks it up. Incomplete tickets bouncing between levels can take more time than the fix itself, and the SLA report rarely shows it, because the clock usually starts only when the vendor accepts the ticket.
A sensible maintenance model makes sure as few tickets as possible reach L3 that L1 or L2 could have resolved. If a vendor’s proposal routes everything through developers, you pay L3 rates for “I can’t log in”. If it has no L3 at all, the first real defect in the code will reveal that nobody can fix it without a separate order. The wider ticket and escalation process is covered under incident management.
Which maintenance pricing models will you see on the market?
Maintenance proposals use four models in practice, and each splits risk between you and the vendor differently.
Fixed retainer. A flat monthly fee for a defined scope: readiness, the SLA, ticket handling and usually a cap on work. It gives a predictable budget and reserved availability. The risk: you pay in quiet months too, and if the scope is described vaguely, every bigger issue turns out to be “outside the retainer”.
Block of hours. You buy a set number of hours per month or quarter, used for tickets and changes. The rules matter: do unused hours roll over, what is the rate for hours above the block, and does the block guarantee availability within a defined time?
Time and materials. You pay for hours actually worked, with no fixed fee. It is the cheapest option when tickets are few, but it guarantees nobody will be available when the system goes down on a Friday evening.
Hybrid. A smaller fixed fee for readiness and the incident SLA, plus a block of hours or hourly billing for changes and enhancements. In practice this is usually the healthiest arrangement, because it separates two things of a different nature: insurance against outages and continued product development.
The risk split mirrors the one we described for choosing a delivery model in team subscription, time and materials or fixed price. The principle is the same: the more risk the vendor takes on, the more it will charge for it.
How do you build the maintenance budget bottom-up instead of guessing a percentage?
A bottom-up budget has three layers: readiness (who is available, and during which hours), work (how many hours a month tickets, updates and changes consume) and infrastructure and tooling. The examples below illustrate the method; they are not anyone’s price list. As a basis we use the rates from our 2026 benchmark for specialists from Poland: a senior backend developer at about €335–485 per day and a senior DevOps engineer at about €370–520 per day.
Example 1: internal application, business-hours support. A system for a few dozen users, a handful of integrations, support during working hours. Your company runs L1, and the vendor provides L2/L3 from a block of five person-days a month. At senior rates that is €1,675–2,425 a month, or €20,100–29,100 a year, plus hosting and licences.
Example 2: customer-facing application, higher traffic. A sales or service system with a dozen or more integrations, frequent dependency updates and regular changes. The vendor provides ten developer days and five DevOps days a month. That is €3,350–4,850 plus €1,850–2,600, together €5,200–7,450 a month, or €62,400–89,400 a year, excluding infrastructure and out-of-hours on-call.
Where do the hours come from? Ideally from history. If the system has been running for a few months, count tickets by priority and their average handling time, then add time for dependency updates and for changes the business has already requested. If there is no history, start with a larger block for the first six months and adjust after a quarter. The first months after go-live almost always generate more tickets than the ones that follow.
Plan the period right after launch separately; it is often called hypercare. In the first weeks users discover cases the tests did not anticipate, migrated data reveals inconsistencies, and integrations run under real load for the first time. During this period you need more availability from the team that built the system than in the steady state. If the contract goes straight from the project to a minimal block of hours, the first weeks will consume a quarter’s budget and the remaining tickets will wait in the queue.
Do not forget the readiness layer either. A block of hours tells you how much work you are buying, not how quickly someone will pick up a ticket. If you need a guaranteed response time, the vendor has to keep someone in reserve even when there are no tickets, and you will pay for that in a fixed fee or a higher rate. That is a fair cost, as long as it is named openly in the proposal rather than buried in the retainer total.
Finally, work out the percentage of build cost as a check. If the build in example 1 cost €150,000, the annual maintenance budget comes to roughly 13–19 percent. That is not a market norm, just the result of this particular calculation, but it lets you see whether a vendor’s proposal is wildly out of line with what you actually need.
What must an SLA contain to mean something in practice?
The SLA in many maintenance proposals looks impressive and says almost nothing. The most common problem: the document defines response time, the time in which the vendor acknowledges a ticket, but says nothing about when the problem will be resolved or contained with a workaround. “Response within 30 minutes” can mean an automated reply from the ticketing system.
A good SLA defines priorities with examples rather than generalities. Critical means, for example, “the system is unavailable to all users, or a defect prevents payments from being taken”, not “serious business impact”. For each priority it sets a response time, a time to restore service or provide a workaround, and a time to a permanent fix, because these are three different things.
A structure worth opening negotiations with looks like this. Critical: the system is down or a key business process has stopped, with a short response time, a defined restore or workaround time and coverage outside business hours if the business needs it. High: an important feature is broken but a workaround exists, handled in business hours. Normal: a defect with limited impact, fixed in the next planned release. Low: cosmetic issues and questions. The actual times depend on how critical the system is and on your budget, but the structure belongs in every contract.
Pay attention to who sets the priority. It works best when the reporter proposes a priority according to the contract definitions and the vendor can change it only with a reason and with the agreement of a named person on your side. Without that rule, critical tickets can be quietly downgraded while the SLA report looks exemplary.
The SLA also has to state the service hours. A four-hour resolution time on a business-days, 9-to-5 basis means a defect reported at 4:30 p.m. on a Friday may be fixed before lunch on Monday. If the system must work at weekends, you need an explicitly written 24/7 mode, or on-call for critical priorities.
The remaining elements are how performance is measured and reported (who measures, in which tool, how often you get a report), the consequences of a breach (most often service credits against the fee for the period, less often contractual penalties) and the list of exclusions. Exclusions matter because that is where most disputes hide: failures in the client’s infrastructure, changes made by third parties, problems with external services. Check whether the list is reasonable or excludes everything that could possibly happen.
Finally, match the SLA to what you really need. The most expensive SLA on every ticket is waste if only one path is critical, payments for instance. It is often better to buy a tight SLA for narrowly defined critical incidents and a looser one for everything else.
What does 24/7 on-call cost, and when do you really need it?
Round-the-clock support is the item that raises maintenance cost the most, and the one most often bought just in case. Covering every hour of the week takes a rotation of several people who know the system, so that none of them is on call without a break. The vendor therefore has to keep a larger team ready than the one actually working on tickets, and readiness itself has to be paid for, whether or not anything happens.
Before buying 24/7 on-call, answer three questions. What does an hour of downtime at night or at the weekend cost you: lost sales, penalties to customers, regulatory exposure? Do outages outside business hours actually happen, and why? Is the whole application critical, or only one function?
For many internal systems the answers lead to the conclusion that business-hours support plus good monitoring and automated alerts is enough. For sales or payment systems, or ones serving customers across time zones, on-call is justified, but it can be limited to the critical incidents defined in the SLA rather than covering every ticket.
Two things lower the cost of on-call more than negotiating the rate. The first is monitoring and continuous monitoring of IT environments, which spots problems before a customer reports them and tells the on-call engineer where to look. The second is automation: a system that restarts a failed service or fails over traffic on its own needs human intervention far less often.
What raises maintenance cost, and what brings it down?
The table below brings together the factors that most affect the annual cost of maintenance and shows how to check them before you sign.
| Factor | What raises the cost | What lowers the cost | How to check before signing |
|---|---|---|---|
| Support hours | 24/7 on-call for every ticket | Business days plus on-call only for critical incidents | Work out the cost of an hour of downtime outside business hours |
| Code and test quality | No automated tests, heavy technical debt | Regression tests on critical paths, clean architecture | Code audit or a test coverage report |
| Integrations | Many external systems, frequent partner API changes | Few integrations, stable and documented interfaces | List of integrations with partners’ change history |
| Dependencies and technology | Outdated framework, unsupported libraries | Current stack, automated dependency updates | Review versions and end-of-support dates |
| Monitoring and automation | Outages reported by users | Alerts, automatic restarts, traffic failover | Check how you learned about the last incidents |
| Team continuity | Maintenance taken over by a team that did not build the system | The same people build and maintain | Ask who exactly will be on the maintenance team |
| Documentation | Knowledge in two people’s heads | Current documentation, procedures, runbooks | Ask for the deployment and backup restore procedure |
| Functional changes | No cap, everything “in the retainer” | Separate block with priorities set monthly | Separate maintenance from development in the proposal |
Most of the savings usually lie not in the hourly rate but in the first three rows. A system with good tests and monitoring, maintained in a mode that matches its real criticality, costs clearly less to maintain than one with no tests and a 24/7 on-call bought just in case.
Which security and regulatory obligations change the scope of maintenance?
Maintenance today is not just fixing defects but also an obligation to respond to vulnerabilities. New flaws in popular libraries are disclosed constantly, and an application whose dependencies nobody updates becomes an easier target every month. The maintenance budget therefore needs a standing line for security updates, independent of user tickets.
If your application is a product you sell on the EU market, you should know the Cyber Resilience Act, Regulation (EU) 2024/2847. From 11 September 2026, manufacturers of in-scope products with digital elements must report actively exploited vulnerabilities and severe incidents, and from 11 December 2027 most remaining obligations apply, including vulnerability handling throughout a support period that, as a rule, must be at least five years unless the product is expected to be used for less. That changes the calculation: maintaining a product is no longer a business decision you can postpone but an obligation lasting years. Whether the regulation applies to your application depends on its nature; systems built purely for your own internal use are in a different position from products placed on the market, so check this with a lawyer.
In the EU financial sector, DORA adds requirements on ICT risk management and on contracts with ICT service providers, including exit strategies. In practice this means the maintenance contract has to cover how the system will be handed to another vendor, and that scenario is worth thinking through in advance. We describe what a vendor switch looks like in practice in switching software vendors mid-project.
Regardless of regulation, put three things in the contract: the time to deploy a fix for a critical vulnerability, responsibility for monitoring vulnerabilities in dependencies, and a regular, for example quarterly, review and update of libraries.
Which questions should you ask a maintenance vendor before signing?
Maintenance proposals are easy to compare on price and hard to compare on substance. These questions help you see what you are actually buying.
What exactly does the fixed fee cover, and what is billed separately? Ask for a list of sample tickets, each marked as inside or outside the retainer. A general answer such as “ongoing maintenance” is an invitation to disputes.
How do you measure and report against the SLA? The vendor should show a sample monthly report: tickets by priority, response and resolution times, SLA breaches and their causes.
Who exactly will maintain the system, and do they know its code? The team that built a system maintains it more cheaply than a team still learning it. If it is a new team, ask how long onboarding into the system will take and what it costs.
What happens when a key person leaves or falls ill? Maintenance that rests on one person is a risk no SLA will cover. Ask about documentation, procedures and how many people on the vendor’s team know the system.
How will you hand the system over if we end the engagement? The answer should cover code and accounts in your name, current documentation, a transition period and rates for knowledge transfer. A vendor unwilling to discuss this before signing will be no more willing after notice is given.
How do you make sure the same defects do not keep returning? A good vendor runs root-cause analysis on critical incidents and proposes changes that reduce ticket volume. Maintenance that handles the same problems month after month suits a vendor billing by the hour, but not you.
What are the red flags in maintenance proposals?
A few signals in a proposal or a conversation should prompt more questions before you move on to negotiating price.
An SLA with response time only. As above, a response is not a resolution. A proposal with no restore time for critical incidents offers no real protection.
No priority definitions, or definitions the vendor sets alone. If the vendor decides ticket priority without clear criteria, the SLA will always be met, because every hard ticket will get a low priority.
A retainer with no cap on work and no list of exclusions. It looks attractive, but in practice it means the boundary will be drawn in a dispute rather than in the contract.
Maintenance where code and accounts sit with the vendor. The repository, cloud, domains and tools must be in your company’s accounts. Otherwise changing maintenance vendor becomes a rescue operation.
A price quoted without looking at the system. A vendor who does not know the code cannot price maintenance honestly. Either it adds a large margin for uncertainty, or it plans to recover it through “out of scope” tickets. A sensible vendor wants to see the code, the documentation and the incident history first.
How does ARDURA Consulting approach application maintenance?
We say this plainly, because it decides whether it is worth talking to us about maintenance at all: we do not offer maintenance as a standalone managed service. We take over maintenance under an SLA after a project we delivered through Software development or rescued through Software Rescue. In that case the team that knows the code is also responsible for maintaining it, which is the cheapest and safest of the arrangements described above.
If your application was built by another vendor and you need a different maintenance team, the route is Software Rescue: we start with the Code Health Audit (from €4,500, 1–2 weeks), stabilise the system and reduce technical debt, and long-term maintenance under an SLA is the fourth phase of that process. The audit also shows what maintenance will realistically cost, because without knowing the state of the code every estimate is a guess.
If you prefer to maintain the system with your own team and are short of people, you can strengthen it with specialists through staff augmentation, described on our IT outsourcing page. Senior rates in our 2026 benchmark are about €335–485 per day for a backend developer, and every engagement starts with a two-week satisfaction guarantee with a free replacement. Rates for individual roles are on our pricing page.
What should you remember before signing a maintenance contract?
The cost of application maintenance is not a single number but the sum of several decisions: which support hours you really need, how many functional changes the business wants, how well the system is tested and monitored, and who maintains it.
Remember five things. First, split readiness, defect fixing, updates and functional changes in every proposal, or the proposals cannot be compared. Second, build the budget bottom-up from hours and roles, and use a percentage of build cost only as a check. Third, make sure only issues that need a developer reach L3. Fourth, insist on an SLA with priority definitions, restore times and service hours, not just response times. Fifth, buy 24/7 on-call only where an hour of downtime really costs money, and invest in monitoring that shortens every intervention.
If your system needs a new maintenance team, or you are not sure what state it is in, see how Software Rescue works or book a call. We will tell you whether to start with an audit, what a maintenance takeover could look like and what it could realistically cost.