Separate the estimate from the assumptions behind it
Maintenance for a web application is the ongoing work required to keep the software secure, stable, and aligned with your business processes after the initial build is complete. It is distinct from hosting costs, which cover the servers and infrastructure, and it is also separate from developing entirely new features. Estimating these costs accurately means understanding exactly which activities fall under maintenance and how they are priced by suppliers.
The most common pricing models for maintenance are monthly retainers, time-and-materials agreements, or prepaid support blocks. A retainer buys a set number of hours per month, while time-and-materials billing charges for actual work done. Prepaid blocks allow you to buy hours in advance and draw them down as needed. Each model shifts a different level of risk between your business and the supplier.
Several variables influence where your estimate will land. The age and stability of your technology stack matter significantly; older frameworks often require more manual intervention to patch. The number of third-party integrations, such as payment gateways, accounting software, or CRM connectors, adds complexity because you are partially dependent on external release cycles. Regulatory requirements, particularly around data protection and accessibility, also introduce periodic maintenance demands that are difficult to predict years in advance.
When requesting an estimate, the goal is not to find a single fixed number that holds true forever, but to establish a predictable baseline for routine upkeep while creating a clear process for handling the unexpected.
To build a realistic estimate, you need to break maintenance down into its operational categories. Not all of these will apply equally to every system, but missing one will leave a gap in your budget.
| Cost area | What to quantify | Budget control |
|---|---|---|
| Security and dependency updates | Every web application relies on underlying software libraries, frameworks, and operating systems. | Access records, test evidence, unresolved risks and the person accountable for remediation. |
| Bug fixing and production support | No software is entirely free of defects. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
| Third-party API management | If your customer portal pulls data from an external CRM, or your internal tool pushes invoices to accounting software, you are at the mercy of those providers. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
| Minor process adjustments | Business processes change. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
Security and dependency updates
Every web application relies on underlying software libraries, frameworks, and operating systems. When a security vulnerability is announced in one of these dependencies, it must be patched. For a SaaS platform handling customer data, this is a non-negotiable, recurring cost. The estimate should account for the labour of testing these updates against your specific configuration before they reach your live environment.
Bug fixing and production support
No software is entirely free of defects. Production support covers the investigation and resolution of issues that users encounter in the live system. The frequency of these issues usually decreases after the initial post-launch period, but it never reaches zero. When estimating, consider whether your supplier defines a bug as a deviation from the original specification, or whether they will charge maintenance rates to fix things that behave as built but fail to meet an evolving business need.
Third-party API management
If your customer portal pulls data from an external CRM, or your internal tool pushes invoices to accounting software, you are at the mercy of those providers. When a third party deprecates an API version or changes its data format, your application must be updated to maintain the connection. A business running a legacy-modernisation project that connects to multiple older external systems should expect higher maintenance costs in this area than a self-contained internal admin panel.
Minor process adjustments
Business processes change. A field might need to be added to a form, a notification rule might need tweaking, or a report might need an extra filter. These are not new features; they are small adjustments to existing functionality. Clarify with your supplier how they classify this type of work. If it falls outside the maintenance scope, your actual ongoing costs will be higher than the stated retainer.
Monitoring and alerting management
While the infrastructure itself incurs hosting costs, someone must monitor the application logs, review error rates, and tune the alerts so that your team is not overwhelmed with false positives. This operational oversight is a core part of maintenance that ensures small technical hiccups are caught before they become business disruptions.
A frequent mistake is relying on a flat percentage of the initial build cost—often cited as 15 to 20 percent—as a maintenance estimate. This rule of thumb is unreliable because it ignores the specific technical debt of the system, the number of integrations, and the criticality of the data involved. A lean, well-architected CRM replacement might cost far less to maintain than a complex, heavily integrated legacy system, even if the initial builds cost the same.
Another common error is failing to distinguish between maintenance and feature development in the contract. If a supplier’s retainer is vague about what constitutes "support," you may find that routine requests are continually reclassified as chargeable enhancements. The estimate you agree on will only hold if the scope of maintenance is tightly defined.
There are also hard limitations to any estimate. A zero-day security vulnerability, a major regulatory change, or a third-party provider going out of business can all cause sudden, significant spikes in maintenance costs. No supplier can accurately forecast these events. The estimate should therefore be viewed as a baseline for operational stability, not a cap on total expenditure.
Before accepting a maintenance estimate or signing a support agreement, run through these checks:
- Scope definition: Does the written agreement explicitly list what is included (patching, bug fixes, minor tweaks) and what is excluded (new features, major architecture changes)?
- Response and resolution times: Are the service levels defined by severity? A critical security breach should have a different response expectation than a minor visual glitch.
- Roll-over and expiry: If you buy a block of hours or a retainer, what happens to unused time? Does it expire, roll over, or carry a credit?
- Source code and access: If you need to switch suppliers, does your team have full access to the code repository, infrastructure credentials, and documentation? Maintenance is far more expensive if a new supplier must reverse-engineer the system first.
- Exit terms: How much notice is required to end the maintenance agreement, and what are the handover obligations?
Finally, remember that security, privacy, and compliance are areas requiring current specialist review. A maintenance estimate from a development supplier covers the technical implementation of patches, but it does not replace the need for independent, up-to-date legal or security audits where your business risk demands them.