Support sounds like insurance bought just in case, which is why it is so often skipped. The problem is that a site does not stand still: browsers, payment systems, search engine rules and certificate expiry dates all move around it. Doing nothing is also a decision — its consequences simply arrive later.
What support actually covers
It is usually pictured as fixing a bit of text and swapping an image. That is the small part. The real list looks different:
-
Updates. CMS, libraries, dependencies. Every skipped update is a known vulnerability that an attacker knows about too.
-
Backups — and checking they restore. A backup nobody has ever unpacked is not a backup, it is a hope.
-
The certificate and the domain. Both expire. An expired certificate turns your site into a browser warning.
-
Forms still working. The most common silent failure — more on that below.
-
Uptime monitoring. So that you find out it is down, not your customer.
-
Content edits. The part support is usually confused with.
The costliest failure is the invisible one
If the site is down you know within the hour. Far worse is the site that works while enquiries stop arriving: a mail password changed, a sending service hit its limit, messages started going to spam. Nothing looks different. Visitors fill the form in, see "thank you", and leave.
This gets discovered weeks later, usually by accident. The only defence is a regular test enquiry plus writing every submission to the database rather than only emailing it. Once enquiries are stored, losing the mailbox stops meaning losing the enquiries.
What breaks on its own
-
Integrations. External services change API versions and retire old ones. Your code keeps calling the old way and one day gets an error.
-
Broken links. A page is deleted and the links to it remain, inside the site and outside it.
-
Layout drifts. Browsers update, new screen sizes appear.
-
Weight creeps up. Every photo uploaded straight from a phone is several megabytes somebody will download on mobile data.
Who is responsible for what
This is where the argument usually starts. Draw the lines in writing, before the first incident:
-
Hosting is responsible for the server being on.
-
The contractor for the code and for the site working.
-
You for the domain, the access and the content.
When the site is unreachable, "whose problem is this" should not take half a day to answer.
Signs support is not really happening
-
You do not know when dependencies were last updated.
-
Nobody has ever restored the site from a backup.
-
You hear about downtime from a customer.
-
Changing a phone number in the header takes a week.
-
Only the contractor has access to the domain and the hosting.
The last one is the worst. It is not about the quality of the work — it is about a change of contractor becoming a negotiation.
What to take away at handover
Even if you are not buying support, you should end up holding:
-
access to the domain, the hosting and the admin panel, on your own email addresses;
-
the source code in your repository;
-
instructions for deploying the site from scratch;
-
where the backups live and how to restore them.
That is exactly the set that makes you independent of any particular supplier.
If the site is running and you are not sure anyone is watching it, we can look at its current state and say what needs attention first.