Launch day feels like the finish line, but for any piece of business software it is really the start of its working life. The booking system, customer portal or internal tool you have just paid for will run on servers that need patching, depend on libraries that publish security fixes, connect to third-party services that change their APIs, and serve users who will soon ask for improvements.
UK small and medium-sized businesses often discover this the hard way: an integration stops working after a provider update, a certificate expires over a bank holiday weekend, or a cyber insurance questionnaire asks how quickly critical patches are applied and nobody knows the answer. This guide explains what maintenance involves, how to structure a support agreement and service levels, and how to budget for it in pounds.
Key takeaways
- Maintenance covers four different kinds of work: fixing, adapting, improving and preventing.
- A written support agreement with clear response times avoids arguments when something breaks.
- Security patching on a fixed schedule supports Cyber Essentials and cyber insurance requirements.
- Budget for maintenance from the start; a common planning range is 15–25% of the original build cost per year.
- Good documentation and monitoring cut support costs more than any discount on hourly rates.
The four kinds of maintenance work
“Support” is often used as a single word for very different activities. Separating them makes it easier to plan and to agree what is included in a monthly fee.
| Type | What it means | Examples |
|---|---|---|
| Corrective | Fixing defects users find | A report showing wrong totals, a form that fails on one browser |
| Adaptive | Keeping the software working as its environment changes | Payment gateway API changes, new browser or operating system versions, HMRC or banking format updates |
| Perfective | Improving and extending | New reports, faster pages, small features requested by staff |
| Preventive | Reducing future risk | Dependency upgrades, security patches, backup tests, performance tuning |
Most surprises come from adaptive work. Software that nobody touches does not stay still; the world around it moves.
What a sensible support agreement includes
Whether your supplier is in London, elsewhere in the UK or overseas, put the arrangement in writing. A good agreement answers these questions:
- Scope: which applications, environments and integrations are covered, and what is excluded.
- Support hours: for example, Monday to Friday during UK business hours, with or without out-of-hours cover for critical incidents.
- Priority definitions and response times: how a problem is classified and how quickly someone will start working on it.
- Included hours: how many hours per month are available for small changes, and how extra work is approved and charged.
- Security commitments: how quickly critical vulnerabilities are patched.
- Reporting: a monthly summary of tickets, uptime, updates applied and recommendations.
- Exit and handover: access to code, credentials and documentation if you change supplier.
Example priority levels
| Priority | Definition | Typical response target |
|---|---|---|
| P1 – Critical | System down or data at risk; no workaround | Within 1–2 business hours (or 24/7 if contracted) |
| P2 – High | Major feature broken; workaround is painful | Same business day |
| P3 – Normal | Minor fault with an acceptable workaround | Within 2 business days |
| P4 – Request | Change request or question | Scheduled into the next planning cycle |
Response time is not the same as resolution time. Agree both where it matters, but accept that complex faults cannot always be fixed to a fixed clock.
Security patching and Cyber Essentials
Cyber Essentials, the UK government-backed certification scheme run with the National Cyber Security Centre’s guidance, expects organisations to use supported software and to apply security updates for high-risk and critical vulnerabilities within 14 days of release. Many public sector contracts and supply chains now require it, and insurers ask similar questions.
Custom software adds its own patching responsibilities on top of operating systems and office applications:
- Framework and library updates (for example Django, React, Laravel or Node.js packages).
- Server and container images, databases and web servers.
- WordPress core, themes and plugins if part of your estate runs on WordPress.
- TLS certificates, which should renew automatically with monitoring as a safety net.
If you cannot say when your web application’s dependencies were last updated, assume they need attention now.
Automated dependency scanning in the build pipeline, a monthly patch window and an emergency process for critical vulnerabilities together make the 14-day expectation achievable without constant disruption.
Monitoring: finding problems before customers do
Good monitoring turns support from reactive to proactive. As a minimum, set up:
- Uptime checks on key pages and APIs from more than one location.
- Error tracking that alerts developers when unusual errors appear after a release.
- Performance metrics for response times, database load and disk space.
- Backup verification with an actual restore test at least quarterly.
- Business checks, for example an alert if no orders arrive during a normally busy period.
Our cloud solutions and DevOps team usually configures monitoring and backups as part of the original deployment, so support starts with visibility rather than guesswork.
When something breaks: a simple incident process
Even well-maintained systems have bad days. What matters is that everyone knows what to do. Agree a short incident process with your supplier and test it once a year:
- Report: one agreed channel (a support email, portal or phone number) so nothing is lost in personal inboxes.
- Triage: the supplier confirms the priority and who is working on it.
- Communicate: regular updates at agreed intervals for P1 and P2 incidents, even if the update is “still investigating”.
- Restore: get the service back first, using rollback or a workaround if needed.
- Review: a brief written summary of cause, impact and actions to prevent a repeat.
Personal data incidents
If an incident affects personal data, UK GDPR may require you to notify the Information Commissioner’s Office within 72 hours of becoming aware of a reportable breach, and in some cases to inform the people affected. Your support agreement and data-processing terms should require the supplier to tell you promptly and to provide the information you need to make that assessment.
Planning upgrades and end-of-life
Every technology stack has a lifecycle. Programming language versions, frameworks and operating systems reach end of support, after which they no longer receive security fixes. Ask your supplier for a simple roadmap showing the support dates of the main components in your system and a plan for upgrading before each one expires. Major upgrades, such as moving to a new major version of a framework or database, are best scheduled as small projects with their own testing, rather than squeezed into routine monthly hours. Planning them a year ahead spreads the cost and avoids the situation where an insurer, auditor or customer asks why your system runs on unsupported software.
Budgeting for maintenance in pounds
A widely used planning assumption is to set aside roughly 15–25% of the original build cost per year for maintenance and small improvements. The right figure depends on how many integrations the system has, how fast your requirements change and how critical uptime is.
| Plan type | Suits | Indicative monthly range |
|---|---|---|
| Essential care | Brochure sites and simple apps: updates, backups, monitoring, a few hours of fixes | £150 – £500 |
| Business support | Customer portals and e-commerce: patching, priority support in UK hours, regular small changes | £600 – £2,000 |
| Product team | Platforms that keep evolving: dedicated or part-dedicated developers plus DevOps | £3,000+ |
These ranges are indicative, exclude VAT and hosting, and should be confirmed against your actual system. For smaller projects, the fixed-price packages in our shop show what a clearly scoped piece of work costs, and support can be added to any of them.
Hidden costs to anticipate
- Third-party subscription increases for APIs, email delivery or maps.
- Major framework upgrades every few years that require more than routine patching.
- Hosting growth as your user numbers and data increase.
- Compliance changes, such as new accessibility or data protection obligations.
Documentation and handover: reducing dependence on individuals
The most expensive support problems come from knowledge that lives in one person’s head. Ask for and keep:
- An architecture overview and diagram showing systems and integrations.
- Deployment instructions and infrastructure defined as code where practical.
- A runbook describing what to do when common alerts fire.
- A register of accounts, domains, certificates and renewal dates, with credentials held in a password manager the business controls.
- A changelog of releases and the reasons behind major decisions.
This protects you if staff change on either side and makes switching supplier possible without starting again.
Choosing a maintenance partner
When comparing providers, look beyond hourly rates. Ask how they classify and prioritise incidents, how quickly they applied the last critical patch for a client, what their monitoring covers, and whether you will deal with the same people each month. Check that support hours overlap with your working day; Creensight UK, for example, combines a London point of contact with the engineering team of Creensight Private Limited in India, with agreed hours that cover the UK morning and early afternoon. If you are planning a new system, include maintenance in the conversation at the start of any custom software project rather than after launch.
Questions to ask in the first meeting
- Who exactly will look after our system, and who covers them during holidays?
- How do you find out about vulnerabilities in the libraries we use, and how quickly did you patch the last critical one?
- What will you need from us to get started: code access, hosting accounts, documentation?
- How do you report on work done each month, and how are additional hours approved?
- If we part company, how and how quickly will you hand everything back?
Clear, specific answers to these questions are usually a better guide to quality than a polished proposal.
Quick health check: list your business-critical systems, who supports each one, when each was last updated and how you would restore it from backup. Any blank answer is a priority.
Frequently asked questions
Do we still need maintenance if nothing seems broken?
Yes. Security updates, browser changes and third-party API changes continue regardless, and preventive work is far cheaper than an emergency fix.
Can you support software another company built?
Usually, after a short code and infrastructure audit to understand its condition and risks. The audit also produces the documentation a support team needs.
What happens to unused support hours?
That depends on the agreement. Some plans roll hours over for a limited period; others use them for preventive work. Make sure the contract states this clearly.
Are your support prices quoted in pounds?
Yes. Creensight UK quotes in GBP, and prices exclude VAT where applicable. More answers are on our FAQ page.
Plan support before you need it
If you have a system that is live but unsupported, or a launch coming up, we can help you set up monitoring, a patch schedule and a support plan that fits your budget. Contact Creensight UK to arrange a review.
