Think Build Implement Repeat
Hiring & Budgets

What a Software Maintenance Contract Should Actually Cover

Last updated:

Three different things with one word attached

  • Maintenance — keeping it working as the world around it changes. Security patches, dependency updates, fixing what breaks.
  • Support — helping people use it. Answering questions, investigating what a user reports.
  • Development — making it do new things.

Nearly every maintenance dispute comes from one side thinking a request was maintenance and the other thinking it was development. Define the boundary in the contract with examples.

What maintenance should include

  1. Security patches for the application and its dependencies, applied on a defined cadence
  2. Fixes for defects — behaviour that does not match what was agreed
  3. Repairs when a third-party integration changes and breaks
  4. Monitoring, with a defined response when something fails
  5. Backup verification, including an actual restore test at least annually
  6. A periodic report of what was done, so you can see what you are paying for

Typical costs

Build costAnnual maintenanceMonthly
£20,000£3,000–£5,000£250–£420
£50,000£7,500–£12,500£625–£1,040
£100,000£15,000–£25,000£1,250–£2,080

The 15–25% range is a reasonable benchmark. Complex integrations and regulated environments push towards the top; simple, stable systems sit at the bottom.

Response times worth agreeing

Define severity levels and response commitments in plain terms: system down, major function broken, minor defect, cosmetic. Agree what response means — acknowledgement, investigation started, or resolution.

“Four-hour response” usually means someone will acknowledge you within four hours, not that it will be fixed. Clarify which, in writing, before you need it.

The questions that prevent disputes

  • Is a bug that has existed since launch a defect or a change?
  • Are dependency upgrades included, or billed separately?
  • What happens when a third party changes their API — maintenance or development?
  • Are hours banked if unused, and do they expire?
  • What is the notice period, and what handover happens if we leave?

Do you need a contract at all

For a simple, stable system with no integrations, ad hoc arrangements can work — pay for time when something breaks. The risk is availability: your supplier may be busy when you need them.

For anything with integrations, users or revenue attached, a contract buys guaranteed attention. Also make sure someone other than the original supplier could pick it up, which means documentation and repository access regardless of who maintains it.

Frequently asked questions

Can we do maintenance in-house?

If you have the skills, yes, and it is often cheaper. Make sure the handover included deployment documentation and that someone owns dependency updates, since that is the part most commonly neglected.

What if we never use the hours?

Ask about rollover before signing. Many suppliers allow unused hours to be used for small improvements rather than expiring, which is a better arrangement for both sides.

Is maintenance negotiable?

The percentage is, particularly for simpler systems. What is worth protecting is the security update cadence and the response commitment — those are the parts you are actually buying.

What happens if we skip maintenance for a year?

Dependencies fall behind, security exposure grows, and catching up becomes a project rather than a routine task. Deferred maintenance is one of the reliable ways a working system becomes a rewrite.

Keep reading

Have software running with no maintenance arrangement?

That is worth reviewing before something breaks. We maintain systems we did not build, and we will tell you if you do not need us.

Book a free 30-minute call Get a project estimate WhatsApp us

Related services

What we build for problems like this one

Custom Software DevelopmentBusiness Automation