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
- Security patches for the application and its dependencies, applied on a defined cadence
- Fixes for defects — behaviour that does not match what was agreed
- Repairs when a third-party integration changes and breaks
- Monitoring, with a defined response when something fails
- Backup verification, including an actual restore test at least annually
- A periodic report of what was done, so you can see what you are paying for
Typical costs
| Build cost | Annual maintenance | Monthly |
|---|---|---|
| £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.