Process
Website support after launch: what it includes
A website isn't a finished product but a running system: updates, backups, monitoring, small edits. How support differs from further development.
Launch is often seen as the finish line: the work is handed over, the acceptance certificate signed, the site open. In fact, that's when operation begins, and it has its own cost. A website doesn't exist in a vacuum — browsers, platforms, payment services and the company itself change around it, which means that without intervention it gradually stops working as intended.
Why a website is never "finished"
A website is a program running around the clock on someone else's hardware and talking to external services. Each of its parts has its own life cycle.
The platform and libraries release updates, including ones that close vulnerabilities. Browsers change behaviour. Payment and email services change their rules and interface versions. Search engines change their requirements. The HTTPS certificate expires. The domain needs renewing. The server runs out of disk space.
None of these events has anything to do with the quality of the original work. It's background pressure from the environment, and the only counter to it is regular maintenance.
A website without support doesn't stay the same. It slowly drifts apart — and people usually notice on the day requests stop coming in.
What support includes
Updates and vulnerabilities
The main part. Platform components are updated, updates are tested, critical ones are released out of turn. Particular attention goes to publicly announced vulnerabilities: as soon as a description is published, automated scanners start looking for vulnerable sites across the internet, and nobody is picking you specifically.
An update isn't always a harmless operation: versions conflict, behaviour changes. So a proper process has a staging copy of the site where the update is checked first, and the ability to roll back.
Backups
Backups aren't a file someone once downloaded to a USB stick. They're a routine: what's backed up (files and the database), how often, how many generations are kept, where exactly the copies are stored and who checks that they're being made.
The key point almost everyone skips: testing restoration. A backup that has never been used to bring the site back up isn't a backup but a hope. Restoration should be rehearsed in advance, not at the moment of an incident.
Monitoring
Someone has to find out about an outage before clients do. The minimum set: site availability checks, certificate and domain expiry tracking, disk space monitoring, application error notifications.
It's also worth checking that requests are sent and delivered. A form can look like it's working while silently losing emails — for example, after the email service tightened its rules.
Small content edits
Change a phone number, add a team member, update a price list file, replace a photo, fix a typo, publish a news item. This is usually what a client means by "support", although in terms of effort it isn't the main part.
It's important to figure out in advance what you'll do yourselves. If the admin panel is convenient and someone in the company has been trained, most edits shouldn't go to a contractor at all.
Technical health
A periodic check-up: whether broken links and error pages have appeared, whether load times have grown, whether the sitemap has broken, whether analytics has dropped off, whether errors in the logs have started to increase. These things don't break the site right away, but they accumulate.
How support differs from further development
The dividing line runs along one criterion: support returns the system to its agreed state; development changes that state.
Support is when a form stopped sending and gets fixed. Development is when three fields and sending to a new CRM need to be added to the form.
Support is updating the platform and making sure the catalogue works as before. Development is adding attribute filters to the catalogue.
Support is replacing a photo in an existing block. Development is building a new photo gallery block.
The line seems obvious, but in practice disputed cases come up constantly, and almost always around the word "tiny". So the agreements should describe not only the scope of work but also the procedure: who classifies a task, what happens in case of disagreement, how the scope is estimated before work starts.
A separate category is fixing bugs introduced during development and found after acceptance. It's neither support nor development, and the terms for it are discussed separately.
What to agree on in advance
Specific terms differ for everyone, and there are no universally "right" values. But the set of questions to ask before signing is always the same.
- Scope of work. What's included, what isn't, what's included up to a volume limit.
- Unit of measurement. Is work counted in tasks, hours or a package? What happens to unused volume?
- Response time. How quickly the contractor responds to a request, and how a response differs from a resolution. Are requests split by severity — "the site is down" and "fix a comma" shouldn't be in the same queue.
- Working hours. Business hours, weekends, holidays. What happens with an outage at night, and on what terms.
- Request channel. One fixed channel with history. Tasks in private messages get lost, and nothing can be proven later.
- Backups. Who makes them, where they're stored, how often, how many generations, who tests restoration and how often.
- Updates. Who decides what to update, whether there's a staging copy, who is responsible for rolling back if there are problems.
- Access. It stays with you. Support is a service, not a hostage situation.
- Reporting. In what form you see what was done over a period.
- Exit. How to terminate, what's handed over when you part ways and within what time.
What to do if there's no support right now
A common situation: the site launched, the contractor left, the question was put off. The minimum steps you can take without a contract:
- Check that access to the domain, hosting and admin panel is in your hands, and that you can log in right now.
- Find out whether backups are being made, and try once to restore the site from a backup.
- Set up at least a simple availability check with a notification.
- Check the domain and certificate expiry dates and turn on auto-renewal where possible.
- Submit every form on the site and make sure the emails arrive. Repeat this once a month.
- Look at which components and versions are in use and how long it's been since they were updated.
These steps cover the most expensive scenarios — losing the site and silently losing requests. The rest can be built up gradually. What exactly your project needs usually becomes clear after a short technical review; our areas of work are described in the services section, and you can discuss your specific situation via the contact form.