A good software maintenance contract says what is covered, how fast problems are handled and how issues are reported. Fixing bugs, updating dependencies and applying security patches are different from building new features, so check which of them are included.
What it should cover
At minimum, it should state which systems are covered, what kinds of work are included and how you ask for help.
- Bug fixes. Correcting behaviour that does not match what was built. Check whether there is a limit on hours.
- Security updates. Patching software and libraries as problems are found.
- Dependency and platform updates. Keeping the software working as the tools beneath it change.
- Monitoring. Watching for outages and errors. Ask whether alerts reach a person.
- New features. Usually separate. Ask how changes are requested and priced.
Vague wording such as "reasonable support" causes disputes. Ask for plain descriptions and examples.
How fast problems should be handled
Look for response and resolution targets by severity. A site outage and a spelling error should not have the same priority. Ask for a table with four severity levels and have every target filled in before you sign:
| Level | Example | Targets |
|---|---|---|
| Critical | The service is down for everyone | First response and target to resolve, agreed in writing |
| High | A main feature fails for some users | First response and target to resolve, agreed in writing |
| Normal | A bug with a workaround | First response and target to resolve, agreed in writing |
| Low | A cosmetic fault | First response and target to resolve, agreed in writing |
The targets depend on how much your business relies on the software, so no figures are suggested here. The point is that no target is left blank, and that "resolve" is defined: a fix released, or a workaround in place.
Three pricing shapes
- Fixed monthly retainer. The same amount each month for a stated scope. Predictable, and suits software that needs steady monitoring and regular updates.
- Block of hours. You buy a number of hours and draw them down. It suits software that changes rarely, but check what happens to unused hours.
- Pay as you go. Billed as the work happens. The cheapest when little goes wrong and the most uncertain when something does.
Whichever you choose, ask what is outside the price. Out-of-hours emergency work, major version upgrades and anything that counts as a new feature are the usual exclusions.
Backups and security: four plain questions
- Are backups taken, and how often?
- Has a restore from backup ever been tested? A backup that has never been restored is an assumption.
- Who is told when a security fix is released, and how soon is it applied?
- Where is your data stored, and who can access it? If it includes personal data, UK GDPR applies to the supplier as well as to you.
What you should be able to see
A record of work done and time spent, reports on incidents and their causes, and a list of known issues and planned updates. If you cannot see what is being done, you cannot judge whether the contract is worth renewing.
Who owns what
You should have access to the code repository, hosting accounts, domains and documentation at all times, not only while the contract runs. A contract that keeps these under the supplier's control makes leaving difficult.
Check before signing
- Which systems and environments are covered?
- What are the response and resolution targets?
- How are changes requested and priced?
- How long is the term, and how do you end it?
- What handover do you get if you leave?
- Who is accountable when something fails?
If a supplier is reluctant to explain any of these in writing, treat that as information.
The full guide is on the Cognivise blog. For how we handle support after launch, see ongoing support and ownership.
Top comments (0)