Maintenance Contracts for Web Apps: What to Include

Launching a web application is a major milestone, but the work does not necessarily stop when the app goes live. Dependencies need updates, bugs appear, integrations change, and users may need help. When something goes wrong, everyone should know who is responsible and what happens next.

That is the purpose of a web application maintenance contract. It sets expectations for ongoing support and maintenance so that both the business and the developer understand what is included, how work is prioritised, and how additional requests are handled.

The agreement does not need to be unnecessarily complicated. It does need to be specific. A vague promise of “ongoing support” can mean different things to the client and the provider.

This guide explains the main sections to review before agreeing to a maintenance arrangement. It is general business guidance, not legal advice; have a qualified professional review terms where appropriate.

1. Define the Scope of Maintenance

Start by identifying exactly which application and components the agreement covers. “Maintain our web app” is too broad to be useful when an issue occurs.

List the relevant items, such as:

The application, domains, and environments covered.
Frontend and backend components included in the service.
Databases and scheduled jobs, if applicable.
Third-party integrations that are supported.
Hosting, DNS, certificates, or infrastructure, if included.
Existing code or components that are excluded from support.

Next, list the actual maintenance tasks and their frequency. These may include routine dependency updates, bug investigation, health checks, minor configuration changes, or a monthly maintenance report.

The scope should also say what is not included. New features, a redesign, a major framework upgrade, a new integration, data cleanup, content writing, or marketing work may require a separate estimate. Explicit exclusions reduce the chance that either side assumes a task is covered when it is not.

2. Separate Maintenance, Bug Fixes, and New Development

These terms are often used interchangeably, but they can describe different kinds of work.

Type of work	Example	How the agreement can handle it
Corrective maintenance	Fixing a reproducible defect in an agreed feature	State when the fix is included and what limits apply
Preventive maintenance	Updating dependencies or addressing known technical risks	Define the tasks and schedule
Adaptive maintenance	Updating the app because a supported platform or external API changes	Clarify which compatibility updates are included
Security maintenance	Applying relevant security patches and investigating vulnerabilities	Define responsibilities and urgency
New development	Adding a new workflow, dashboard, or payment option	Usually scoped and estimated separately

The exact definitions should match the application and agreement. For example, a small defect caused by a recent change may be treated differently from a problem in legacy code that was not previously reviewed.

If a bug is discovered, the agreement should clarify how it will be assessed and whether it falls within maintenance, a separate warranty or defect-correction period, or additional billable work.

3. Set Support Hours and Communication Channels

A maintenance contract should explain when support is available and how the client should report an issue.

Specify:

Support days and hours.
The time zone used for support commitments.
Whether weekends and public holidays are covered.
The approved reporting channel, such as email or a ticketing system.
How urgent incidents should be flagged.
Who to contact if the primary person is unavailable.

Do not assume that a monthly maintenance fee automatically includes round-the-clock support. If the application needs overnight or weekend coverage, confirm who will provide it and whether the provider has a realistic backup arrangement.

For a small business website, support during agreed business hours may be sufficient. A business-critical application used continuously may need a different plan, escalation process, and budget.

4. Define Severity Levels, Response Times, and Resolution Targets

Not every issue has the same business impact. A complete outage is different from a small visual defect, so the agreement should define how incidents are prioritised.

A simple example might look like this:

Priority	Example	What to define
Critical	The application is unavailable or a core transaction cannot be completed	How quickly the provider acknowledges and begins investigating; escalation route
High	A major feature or integration is failing for many users	Response target and next steps for a workaround or fix
Normal	A limited issue has a workaround	Expected review window and planned resolution process
Low / request	A cosmetic change or enhancement	How it is queued, estimated, and approved

Avoid copying response-time numbers from another provider without considering your application's needs and the actual support capacity. Agree on realistic targets that can be measured.

Response time is not the same as resolution time. A response may mean the provider has acknowledged the issue and started diagnosis. Resolution may take longer because the cause is unknown, a third-party service is unavailable, or a change needs testing. Define the terms clearly and distinguish a workaround from a permanent fix.

If you need a formal service-level agreement (SLA), specify how the clock starts, what pauses it, how priority is assigned, and how performance is reported.

5. Specify Security and Dependency Updates

Web applications depend on frameworks, libraries, plugins, runtimes, and external services. Some need regular updates; others may require urgent action when a serious vulnerability is identified.

The contract should clarify:

Which updates are included in routine maintenance.
How security issues are prioritised.
Who monitors relevant advisories or alerts.
Whether updates are tested in a staging environment before release.
How potentially breaking changes are assessed.
Who approves a production update when approval is required.
Whether major-version upgrades are included or quoted separately.

A routine dependency update is not always equivalent to a major migration. A major upgrade may require compatibility work, code changes, regression testing, and a separate release plan.

The agreement should also address what happens if an update causes a problem: how the issue will be investigated, whether rollback is available, and how remediation work is treated under the contract.

6. Define Backups, Retention, and Recovery

Backups are valuable only if the required data can be recovered when needed. The contract should identify who is responsible for creating, storing, monitoring, and restoring backups.

Clarify:

Which data and files are backed up.
How often backups are created.
How long backups are retained.
Where copies are stored and who can access them.
Whether backup storage is separate from the production environment.
How often restore procedures are tested.
Who can authorise a restoration.
Whether restoration work is included in the maintenance fee.

For applications where data loss would be costly, discuss two useful concepts:

Recovery Point Objective (RPO): the amount of recent data the business can afford to lose, expressed as a time interval.
Recovery Time Objective (RTO): the target time within which the service should be restored after a disruption.

These targets should reflect the business impact and the technical setup. Do not promise recovery targets unless the backup system, infrastructure, and available support can reasonably meet them.

7. Clarify Monitoring and Reporting

Monitoring can help detect problems before users report them, but “monitoring included” should have a clear meaning.

Specify which checks are covered. Depending on the application, these might include availability, application errors, scheduled jobs, certificate expiry, integration failures, or selected performance indicators.

Also clarify:

Which tools or signals are used.
Who receives alerts.
Who investigates an alert and during which hours.
What is considered an incident rather than a routine notification.
Whether monitoring and third-party tool costs are included.
How often the provider reports on completed work and outstanding risks.

A monthly report might list maintenance tasks completed, updates applied, incidents investigated, known issues, and recommended follow-up work. Reports should be useful enough to explain what was done and what still needs attention.

Monitoring is not a guarantee that every problem will be detected before users notice it. The agreement should set realistic expectations about what is monitored and how alerts are handled.

8. Agree on Included Hours, Fees, and Additional Work

Maintenance can be priced in different ways: a fixed monthly fee, a defined allowance of hours, a support package, or time-and-materials billing. The right model depends on how predictable the workload is and what level of coverage the business needs.

The commercial section should answer:

What the recurring fee covers.
Whether there is a monthly hour allowance or request limit.
How time is recorded and reported.
Whether unused hours expire or roll over.
The rate for work beyond the included allowance.
Whether emergency work has a different rate.
How third-party subscriptions, hosting, and other expenses are billed.
How fee changes and renewals are handled.

Be cautious with phrases such as “unlimited support” unless the agreement defines what that means, what types of requests qualify, and whether fair-use or other limits apply.

A clear pricing model helps both sides plan. It also makes it easier to decide whether a new request should be added to the maintenance queue or treated as a separate project.

9. Define the Client's and Provider's Responsibilities

Maintenance works best when responsibilities are shared explicitly.

The provider may be responsible for agreed technical tasks, reporting, and communicating risks. The client may need to provide timely approvals, maintain subscriptions, supply access to relevant accounts, and identify a person who can make decisions.

The contract should clarify who controls:

Hosting, domain, and cloud accounts.
Source code repositories.
Production credentials and access permissions.
Third-party subscriptions and API keys.
Data ownership and access requests.
Approval of releases or potentially disruptive changes.
Communication with other vendors when a problem crosses systems.

Where possible, accounts should remain under the client's ownership, with the provider granted only the access required to perform the work. Credentials should be shared and stored through appropriate secure methods rather than embedded in code or sent casually in messages.

If the provider handles personal or sensitive information, the agreement may need additional confidentiality, data protection, and access-control terms based on the applicable law and the work being performed.

10. Explain Change Requests and Approval

Maintenance often reveals opportunities to improve the product. A client may ask for a new report, a redesigned screen, a new integration, or a workflow that was not part of the original application.

The agreement should describe how these requests are handled. A sensible process is to record the request, clarify the desired outcome, estimate the work, identify effects on the timeline or maintenance allowance, and obtain approval before proceeding.

Also decide who can approve additional work and what form of approval is accepted. This avoids disputes about whether a conversation or informal suggestion was intended to authorise billable development.

Emergency fixes may need a faster process, but the agreement should still define who can authorise them and how the work and cost will be documented afterward.

11. Address Third-Party Services and External Dependencies

Web applications often depend on services outside the developer's control, such as payment gateways, email providers, hosting platforms, identity systems, or external APIs.

The contract should explain what the provider will do if an external service changes, becomes unavailable, or stops supporting an integration.

For example, investigating a failed API request may be included in routine troubleshooting, while rebuilding an integration after a provider retires an endpoint may require a separate estimate. The agreement should make that distinction clear.

It should also identify who pays for third-party subscriptions and who is responsible for contacting the vendor. A maintenance provider can investigate and coordinate within the agreed scope, but cannot guarantee the availability or behavior of an independent service.

12. Cover Ownership, Documentation, and Exit Terms

The agreement should make it possible for the business to continue operating the application if the maintenance relationship ends.

Clarify ownership and access to the code, data, domains, hosting accounts, and documentation, according to the project's existing agreements and applicable law. Avoid leaving essential access solely with an individual provider.

The exit section should cover:

Required notice period and termination process.
Outstanding fees and work in progress.
Delivery or confirmation of agreed source code and documentation.
Transfer or revocation of accounts and credentials.
Backup delivery or data return, where applicable.
Handover assistance and whether it is included or billed separately.
Deletion or retention of data in line with the agreement and applicable requirements.

A handover should be practical, not just a promise to “provide access.” Identify the files, accounts, instructions, and information the next person will need.

13. Include a Review and Renewal Process

A maintenance agreement should be revisited when the application or business changes significantly. The original plan may no longer fit after the product adds users, new integrations, more critical workflows, or stricter availability requirements.

Set a review point—such as a renewal date or periodic service review—to discuss incidents, recurring issues, actual workload, upcoming upgrades, and whether the current support level remains appropriate.

If the business now depends on the application more heavily, it may need stronger monitoring, more frequent backups, shorter response targets, or additional support coverage. If the application is used less often, a simpler arrangement may be sufficient.

Changes to the agreement should be documented and approved by both parties.

Web Application Maintenance Contract Checklist

Use this checklist when comparing a proposal or reviewing an existing agreement.

The covered application, environments, and components are identified.
Included tasks and their frequency are listed.
Exclusions and separately billable work are explicit.
Bug fixes, security maintenance, upgrades, and new features are distinguished.
Support hours, time zone, channels, and escalation contacts are defined.
Incident severity levels and response targets are documented.
Response, workaround, restoration, and resolution are not confused.
Security updates and testing procedures are covered.
Backup frequency, retention, storage, and restore testing are defined.
Monitoring responsibilities and reports are described.
Fees, included hours, overage rates, and third-party costs are clear.
Client and provider responsibilities are assigned.
Source code, account ownership, credentials, and documentation are addressed.
Change requests require a clear estimate and approval process.
Termination, data return, and handover terms are included.
Renewal and periodic review arrangements are clear.

Final Thoughts

A useful web application maintenance contract is not simply a monthly price and a promise to fix problems. It is a shared understanding of what is maintained, what happens when something breaks, how updates and recovery are handled, what the client pays for, and how control of the application is preserved.

The most important parts are often the boundaries: what is included, what is excluded, how urgent issues are handled, and what happens when the relationship ends. Clear terms make it easier to budget, prioritise work, and avoid relying on assumptions during an incident.

If you need help maintaining an existing web application or want to discuss the support your product may require, get in touch with details about the application, its current setup, and the kind of support you are looking for.