Most companies have no website maintenance contract at all — or one that turns out useless in a crisis. As long as everything works, no one looks at it. The problem shows up exactly when the site goes down, the developer stops replying or the domain expires: suddenly nobody knows who is responsible for what, or where the access is. A good maintenance contract isn’t bureaucracy — it’s a continuity policy. Here, from a developer’s perspective, is what it should actually cover.
1. Scope of maintenance — what’s in, what’s out
The most important and most often skipped point. The contract should clearly list what ongoing care covers:
- updates (system, plugins, libraries, certificates),
- backups and their restoration,
- availability and security monitoring,
- minor content changes.
And just as importantly — what it does NOT cover: new pages, rebuilds, integrations, campaigns. Without that line, every conversation ends in a dispute over “wasn’t that included?“.
2. Response time and availability
This isn’t about corporate SLAs with penalties, but about a clear answer to one question: how quickly will someone react when the site stops working? A critical outage (site down) warrants a different response time than a minor edit. It’s enough that it’s agreed and realistic — worse than a slow response time is no response time at all.
3. Backups
A backup nobody has ever restored isn’t a backup — it’s a hope. The contract should specify: how often copies are made, how long they’re kept, where (ideally off the production server) and whether restoration is tested. That’s the difference between “an unpleasant outage” and “an unrecoverable disaster”.
4. Ownership and access — the critical point
This is where it’s decided whether you control your online presence or are hostage to a developer. Whether you keep the infrastructure yourself or entrust it to a developer, one thing matters: whether you can leave at any time — recover your domain, data and code and move them elsewhere. The red flag isn’t that the domain sits with the developer, but the inability to get it back: when you have no access, don’t know the registration details and can’t move without a fight. We wrote about this in „Your web vendor disappeared”.
5. Hosting, domain and email — who pays and watches renewals
Who pays for hosting and the domain, on what cycle, and — crucially — who watches the renewal dates. An expired domain is one of the most common and most painful outages, and almost always avoidable. The contract should clearly name who’s responsible. (We break down the costs themselves in „What does website maintenance really cost”).
6. The line between maintenance and development
Maintenance is caring for what exists. Development is adding what’s new. The contract should name that line and set how development is billed (hourly rate, a block of hours, separate quote). Otherwise either the developer does “while we’re at it” work they aren’t paid for, or the client pays a retainer and hears “that’s a separate project” at every request.
7. Reporting and termination
Two things people remember least often:
- Reporting — whether and how you learn what was done (updates, incidents, hours used). It doesn’t need to be elaborate; it should give the sense that someone is actually looking after the site.
- Termination and handover — what happens when the partnership ends. A good contract includes an orderly handover of access and data, not silence and a disappearance. This is paradoxically the most important clause, because it protects you at the hardest moment.
Red flags
Before you sign, check whether the contract (or its absence) hides these traps:
- access and accounts held solely by the developer,
- a closed system you don’t have full access to or documentation for — one you can’t leave without the developer’s consent,
- no backups whatsoever,
- “everything beyond keeping the server on costs extra”,
- no clause on handing the project over when the partnership ends.
How we approach it at Invisio
In practice, many clients also entrust us with hosting and the domain — we run it in a managed model: we keep the infrastructure, updates, backups and renewals on our side, so you don’t have to deal with the server, database or control panel. If you’d rather have your own access (e.g. via FTP), or keep the site on your own server and just grant us access — we work that way too. We’re flexible; it’s a matter of how best to divide the responsibilities.
This model doesn’t mean lock-in. What matters to us isn’t where your site physically sits, but that you can leave at any time. If you decide to part ways, we hand over the domain’s auth (EPP) code and help you move the site and data wherever you want, in an orderly way.
Everything discussed above — scope, response times, the line between maintenance and development, the notice period — is spelled out in our openly published pricing: website care plans start at PLN 300 net per month.
If you’re not sure what your current care covers (or whether you even have any) — get in touch. We’ll help bring order to access, hosting and scope, before an outage does it for you.