Maintenance and continued development
Website and system maintenance
Maintenance is often bought as "support", and only later does it emerge that both sides understood the word differently. So it is more useful to agree not on a label but on four things: which work is included, which is not, how quickly you get a response, and who holds the access. The fourth matters most — if access and backups belong only to the supplier, a maintenance agreement becomes a dependency rather than a service.
Discuss a maintenance scopeIn short: what to settle
Three things are worth answering before signing. Whether maintenance covers only keeping things working or also building new things — the most common misunderstanding. How response time differs from resolution time, because they are not the same and only one of them can honestly be committed to. And who holds access to the domain, the hosting and the backups. With those three written down, the rest of the agreement becomes detail.
When maintenance is the right arrangement
- The website or system is already in business use, so downtime has a real cost rather than being an inconvenience.
- You need to know who answers when something stops working in the evening or before a weekend.
- The libraries and platform version in use are old — updates are needed even with no feature changes.
- You want to develop the product gradually rather than commission a separate project for every change.
When something simpler is enough
- The system is not critical and rarely changes — individual requests as needed may be enough, with no standing agreement.
- You have your own team and need only review or advice — a limited advisory arrangement fits better.
- You only use a closed platform maintained by its vendor — then the scope is just your content and settings.
Types of maintenance arrangement
Below is an illustrative comparison of arrangement types, to help you prepare for a conversation. It is not a price list and not an offer: the actual scope depends on the system, its age and how quickly you need a response. The third column lists cost factors rather than amounts.
| Arrangement | What it covers | Limits and cost factors |
|---|---|---|
| Keeping it working only | Updates, backups, security patches and fixing faults. | Excludes new features; those are commissioned and planned separately. |
| Maintenance plus small changes | The same, plus small content and interface changes within an agreed time allowance. | You need to agree what counts as a small change, so the boundary is not renegotiated each time. |
| Maintenance plus continued development | Keeping it working, plus planned new work against a priority list. | Requires your involvement in setting priorities; scope is planned in cycles. |
| Fault response only | Involvement only when something stops working. | No prevention, so faults are more frequent, and fixes take longer against an unfamiliar state. |
| Handover to your team | Documentation, an access inventory, training and temporary support during the transition. | Time-boxed work with a defined end point, rather than a standing agreement. |
How the work runs
- 01
State review and access inventory
First we establish what actually works: which versions are in use, where the backups are, and whether any of them has ever been restored. At the same time we record access and who owns it. Without this step any response time would be a guess.
- 02
Agreeing scope and response
We write down which work is included, which is not, and how response time differs from resolution time. Response time can be planned; resolution time depends on the problem, so it is described as a process rather than a promise.
- 03
Prevention and monitoring
Libraries and platform versions are updated regularly, and backups are checked by restoring them. Fault reporting is set up so a problem is noticed before a user notices it.
- 04
Development and staying handover-ready
Changes are planned in cycles against your priorities, and documentation is updated alongside them rather than at the end. That keeps a handover to another team possible at any point instead of being its own project.
What drives cost and duration
- The age of the system and how far behind its library versions are — the further behind, the more work in the first stage.
- The response time required, and whether work outside business hours is needed.
- Whether maintenance covers only keeping things working or also building new parts.
- The number of integrations with external systems — each boundary has its own failure cases.
- The state of documentation and tests at takeover; their absence lengthens every later change.
Worth considering before we talk
- 01Should maintenance cover only keeping things working, or also building new parts?
- 02What response time do you genuinely need, and is work outside business hours required?
- 03Who holds access to the domain, the hosting and the backups today?
- 04Has a backup ever been restored, or is it only being created?
- 05What happens when the agreement ends: how, and how quickly, is access transferred?
Let us scope the maintenance
A note about which system you run and what worries you most today is enough. Please do not send logins, passwords or real customer data — a general description is a fine starting point.