After launch it feels like the work is done. The site opens, the form sends, the bot replies. But the site lives on a server whose software gets updated, the certificate has an expiry date, the domain has a renewal date, and in a month you will need to change a price or add a service.
Support is not needed because the site will break tomorrow. It is needed so that someone knows in advance what to check, and so that a small edit does not turn into a search for a developer. Below is what support usually covers, what it does not, and how to agree on it so both sides mean the same thing.
Backups
A copy of the site files and the database is made on a schedule and is not stored only on the same server. If the server goes down or gets hacked, a copy sitting next to it will not help. It is good when one copy lives with the hosting provider or in the panel and another in separate storage.
A backup nobody has ever restored from is not tested yet. Every so often, deploy it to a test address and make sure the site comes up and the form works.
Updates
The CMS, plugins, libraries, and the PHP or Node version on the server age over time. Updates close vulnerabilities but sometimes break compatibility. So update on a plan: a backup first, then the update, then a check of the main pages and the form, not “click everything at once on a Friday evening.”
A static site without a CMS has almost nothing to update except the server itself. That is one reason support for simple sites is lighter.
Certificate, domain, and server
- The SSL certificate renews automatically, and someone checks that the renewal actually happened
- The domain renewal date is known, with a reminder set well ahead
- Hosting or the VPS is paid, and it is clear whose card pays
- There is a simple uptime check: if the site stops opening, an alert arrives
Each of these is boring until it happens. A site that will not open because of an expired certificate looks to a visitor exactly like a site that does not work at all.
Requests and bots
A form that worked at launch can stop delivering: mail settings changed, the mailbox filled up, messages started landing in spam. A bot can go silent if the server rebooted and the process did not come back. A simple regular check, a test request and a message to the bot, catches this before clients do.
Small edits
Change a price, a phone number, a photo, add a news item or a service from an existing template. Edits like these fit well into support, so each one does not need its own estimate. To keep an edit quick, send it like this:
- The address of the page that needs the change
- What is there now and what it should be, in text rather than a voice note
- A screenshot, if it is about a spot on the page
- All edits in one list, not one at a time through the day
What support does not cover
A new section, a new integration, a redesign, a catalog instead of a single page. That is further development, with its own estimate and its own timeline. The line between an edit and development should be written down in advance. Otherwise, six months later, it turns out you thought support meant one thing and the developer another.
How to agree on it
- What is checked regularly, and how often
- Where backups are kept and who can restore the site from them
- Which edits are included and which are quoted separately
- How quickly the developer answers a normal request and an emergency
- Where to write if the site does not open
- What happens to access if support ends
The format can be anything: a monthly package, pay as you go, or an agreement for emergencies only. What matters is that the answers to these questions are written down, not kept in one person’s memory.
What should stay in your hands when a contractor runs support is covered in the note on domain, hosting, and access. Why a quote has a support line is in the note on what a site costs. To discuss support for your site, use the contact form.