Application maintenance costs 15–25% of the original build price every year, and it is not optional. That figure covers security patching, dependency and platform updates, monitoring, incident response and small fixes, before a single new feature. A product budgeted without it works, then decays, because there is no line to fund the work that keeps it alive.
This guide covers what maintenance actually includes, what it costs, how to structure a support agreement, and which metrics tell you whether the arrangement is working.
Key takeaways
- Budget 15–25% of build cost annually: Below 10% the product decays; above 30% something is structurally wrong.
- Maintenance is not enhancement: Keeping it working and making it better are separate budgets with separate approvals.
- Response time is the term that matters: "Best effort" is not a support model if downtime costs revenue.
- Platform deadlines are not optional: OS releases and store requirements arrive on someone else's schedule.
What maintenance actually covers
| Category | What it is | Share of effort |
|---|---|---|
| Corrective | Fixing defects found in production | 20–30% |
| Adaptive | Keeping up with OS, browser, platform and dependency changes | 25–35% |
| Preventive | Refactoring, monitoring, dependency hygiene, security patching | 20–30% |
| Perfective | Small improvements to what already exists | 15–25% |
Adaptive work is the category buyers do not expect. Mobile platforms release annually and enforce new requirements, target SDK versions, privacy declarations, account deletion, with deadlines you do not control. An app left untouched for two years will eventually stop being distributable, without anyone having changed a line of it.
What it costs
| Build size | Annual maintenance | What that buys |
|---|---|---|
| $20,000–$35,000 | $3,000–$8,000 | Security patching, platform updates, small fixes |
| $35,000–$60,000 | $6,000–$15,000 | The above plus monitoring and defined response times |
| $60,000–$100,000 | $10,000–$25,000 | The above plus proactive work and a change allowance |
These figures exclude hosting and third-party services, which are separate and run from a few hundred to several thousand a year depending on traffic.
Spending under 10% of build cost annually is the pattern that produces the "it worked fine for two years and now nothing works" conversation. The work did not disappear; it accumulated.
Structure the agreement around response, not hours
An agreement measured only in hours per month rewards consuming hours. One measured in response and resolution commitments rewards keeping the product healthy.
| Severity | Definition | Typical response | Typical resolution |
|---|---|---|---|
| Critical | Product unusable or data at risk | 1–2 business hours | Same day |
| High | Major function broken, workaround exists | 4–8 business hours | 2–3 days |
| Medium | Minor function affected | 1–2 business days | Next release |
| Low | Cosmetic or improvement | Acknowledged | Backlog |
Define who classifies severity, and what happens when you and the supplier disagree, that argument is guaranteed and is easier to settle in advance.
Agree coverage hours explicitly. If your product transacts on Saturdays, business-hours support does not cover you, and peak trading periods deserve their own clause.
Separate keeping it working from making it better
Bundling maintenance and enhancement into one retainer means one always consumes the other, and it is usually enhancement that wins until something breaks.
Fund them separately: maintenance as a fixed annual commitment, enhancement as a change budget of 10–20% of build cost per year for a product you expect to develop. That way security patching is not competing with a feature request, and the trade-off is visible when it does need making.
Insist on monitoring you can see
Maintenance without monitoring is waiting for users to report problems. At minimum: uptime checks, error rate and crash-free session rate, performance for the journeys that matter, and alerting to someone who can act.
You should have access to the dashboards. A support arrangement where only the supplier can see the product's health makes it impossible to judge whether you are getting value, and it makes changing supplier harder than it should be.
Set business-level alerts too: orders per hour, payments cleared, records synchronised. A system returning success responses while writing nothing is the failure that hurts most, because every technical dashboard says it is healthy.
Keep dependencies current, continuously
Dependencies age whether or not you touch the code. A framework two major versions behind turns a routine update into a project, and a known vulnerability in a common library becomes your problem the day it is published.
Update on a schedule rather than in response to alarm. Small, frequent dependency updates are ordinary maintenance; a deferred two-year update is a migration, and it will be quoted as one.
Protect the ability to change supplier
Maintenance arrangements quietly create lock-in. Reduce it deliberately: code in a repository you own, infrastructure in accounts in your name, documented deployment, and a runbook that does not require the original developer.
Ask what a handover would involve before you need one. A supplier who has done it before will describe a process; one who has not will treat the question as a lack of trust, which is itself the answer.
Review it annually against evidence
Once a year, look at incident count and severity, response times against commitments, how much of the retainer went to corrective versus preventive work, and whether lead time for a small change is stable or growing.
Rising corrective work with flat preventive work means debt is accumulating and the arrangement is treating symptoms. That is the moment to change the shape of the agreement rather than the moment to renew it unchanged.
Related guides
- Alongside Application Maintenance: Support, Monitoring, and Releases, continue with How to Build a Business Case for Custom Software.
- Alongside Application Maintenance: Support, Monitoring, and Releases, continue with How to Choose a Digital Transformation Partner.
If the work prompted by Application Maintenance: Support, Monitoring, and Releases leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Software Project.
Ali Boran Gazel