Web Development

Software Maintenance Contracts: What They Should Cover

Custom software keeps costing money after launch, and a vague maintenance agreement is where many disputes start. Here is what a software maintenance contract should cover, how pricing usually works, and the clauses worth checking before you sign.

Quick answer: A software maintenance contract sets out how a developer or agency will keep your application working after launch. It should define which types of work are included, such as bug fixes, security patches, dependency and server updates, monitoring and backups, and which are extra, such as new features. It should also state response and fix times by severity, how many hours are included, how unused hours and overages are handled, who owns the code and accounts, and what happens if either side ends the agreement. Clear scope prevents most of the disputes that arise later.

Why software needs ongoing maintenance

Custom software does not stay finished. Even if nobody changes a line of your code, the world around it changes:

  • Operating systems, programming languages and frameworks release security updates and eventually stop supporting old versions
  • Third-party APIs change or retire endpoints
  • Browsers and mobile devices update and expose new display issues
  • Security flaws are discovered in libraries your code depends on
  • Data grows and slows down queries that were once quick
  • Users find bugs that testing missed

Software left alone gradually becomes harder and more expensive to fix. This build-up is often called technical debt. Our guide to technical debt explains how it grows.

The four types of maintenance

Software engineers often split maintenance into four categories. They are useful when agreeing scope.

Corrective

Fixing bugs and errors found after launch. For example, an invoice total that rounds incorrectly or a form that fails on a certain browser.

Adaptive

Changes needed to keep the software working in a changing environment, such as upgrading to a supported framework version, moving to a new server or updating an integration when a third-party API changes.

Preventive

Work that reduces future problems: updating libraries, refactoring fragile code, improving tests, monitoring, and cleaning up logs or old data.

Perfective

Improvements and small enhancements based on user feedback, such as a new report filter or a faster search.

Most contracts include corrective, adaptive and preventive work within a monthly fee. Perfective work and new features are often handled separately, either from a bank of hours or as quoted projects.

What a maintenance contract should include

Clear scope of included work

List exactly what the monthly fee covers. A good list might include:

  • Fixing defects in existing functionality
  • Applying security patches to the framework, libraries and server software
  • Minor version upgrades of dependencies
  • Monitoring uptime and errors
  • Managing backups and testing restores
  • Renewing SSL certificates and domains, if the agency manages them
  • A set number of hours for small changes

Equally important is what is not covered, such as major version upgrades, new features, redesigns, data entry or problems caused by changes someone else made to the code.

Response and resolution times

Not every issue is urgent. Define severity levels and response times for each:

Severity Example Response time Target fix
Critical System down, data at risk, security breach 1 to 2 hours Same day
High Key feature broken, no workaround 4 business hours 1 to 2 days
Medium Feature broken with workaround 1 business day Within a week
Low Cosmetic issues, minor bugs 2 business days Next scheduled release

The numbers above are examples. Agree on what is realistic for your business and your budget. Twenty-four hour cover costs more than business hours cover.

Note the difference between response time, when someone acknowledges and starts looking at the problem, and resolution time, when it is fixed. Many contracts guarantee the first but only target the second.

Hours and pricing

Common pricing models:

  • Fixed monthly retainer with a set number of hours. Predictable, but check what happens to unused hours.
  • Bank of hours bought in advance and used as needed, often at a discount.
  • Pay as you go at an hourly rate. Flexible, but no guaranteed availability.
  • Fixed fee for defined tasks, such as monthly updates and monitoring, with extra work quoted separately.

Ask whether unused hours roll over, expire or can be used for other work, and how overages are approved and billed. Our article on fixed price vs time and materials discusses the wider trade-offs between pricing models.

Warranty period versus maintenance

Many development contracts include a warranty, often 30 to 90 days after launch, during which the developer fixes defects in the work they delivered at no charge. Maintenance usually starts after that. Make sure the two do not overlap or leave a gap, and that the difference between a warranty defect and a new request is clear. Our guide to web development contracts covers warranty clauses.

Hosting and infrastructure

State who is responsible for hosting, server updates, backups, domain names and third-party services, and who pays for them. If the agency manages the servers, the contract should cover uptime targets, backup frequency, how long backups are kept and how restores work. Our guide to disaster recovery explains what to ask.

Monitoring and reporting

Ask for regular reports covering work done, hours used, updates applied, incidents and recommendations. Monthly is typical. Good reports also flag upcoming risks, such as a framework version reaching end of life.

Ownership and access

Make sure you own the source code and have administrator access to:

  • The code repository
  • Hosting and server accounts
  • Domain registrar and DNS
  • Third-party services and API keys
  • Documentation

If the relationship ends, you should be able to hand everything to another developer without having to rebuild. Our article on website version control explains why keeping code in a repository you control matters.

Security and data protection

If the developer can access personal data, the contract should cover confidentiality, data protection obligations such as GDPR where they apply, how access is secured and how breaches are reported.

Termination and handover

Include a notice period, what happens to prepaid hours, and a handover obligation: up-to-date documentation, credentials and a reasonable amount of help transferring knowledge.

Red flags in a maintenance proposal

  • No list of what is included, only a monthly price
  • Code or accounts held in the agency’s name with no transfer clause
  • Response times with no definition of severity
  • “Unlimited” support with no detail on how it works
  • No mention of security updates or backups
  • Long lock-in periods with steep exit fees

Before you sign: get a code audit

If you are taking over software built by someone else, the new maintainer will want to understand its condition first. A code audit reviews structure, security, dependencies and test coverage, and gives both sides a realistic picture. Our guide to code audits covers what is involved.

For older systems that are expensive to maintain, it may be worth comparing maintenance costs against modernisation. See our article on legacy system modernization.

FAQ

How much does software maintenance cost?

It depends on the size and age of the system, the technology, the level of cover and how much change you expect. Many businesses budget a yearly amount as a share of the original build cost, but the right figure comes from the scope you agree.

Is website maintenance the same as software maintenance?

They overlap. Website maintenance usually focuses on CMS, plugin and content updates. Software maintenance covers custom code, integrations and infrastructure. Our WordPress maintenance guide covers the website side.

Can I skip maintenance and fix things when they break?

You can, but problems tend to be bigger and more expensive when they finally surface, and security flaws may be exploited before anyone notices.

Should the original developer maintain the software?

Often that is easiest, since they know the code. But it is not required, as long as you own the code and documentation.

Clear scope, fewer surprises

A good maintenance contract keeps your software secure and working, and makes it clear what you are paying for each month. Define the scope, severity levels, hours, ownership and exit terms before you sign. If you need custom software built and supported properly over the long term, see our Custom development service.

About the author

Imran M

Leave a Reply

Your email address will not be published. Required fields are marked *

Ready to improve your website?

Let's build a faster, higher performing website.