Handing over a website isn't the end of the project — it's the start of its operational life. Yet most inquiries only think as far as launch: how much does it cost to build? The real question, though, is what keeps it alive over the following three years. This article is about what happens after launch, and what you need to commission as a result.

Why is a website never truly "done"?

Your site is a running piece of software connected to the internet. That means everything around it keeps changing even if you never touch it: security vulnerabilities surface in the components it uses, browsers change, regulations change, and automated attack attempts keep arriving. A site left to itself doesn't stay stable — it slowly deteriorates.

The five pillars of operations

1. Backups — and, more importantly, restoration

A backup on its own is worth nothing. What's worth something is that the restore has actually been tested. There are two numbers worth knowing about your own site: how much data you'd lose at most (when was the last backup), and how long it would take to restore service. If you can't answer these, you currently don't have a backup strategy — just backup files.

2. Updates

Framework, runtime, libraries, plugins. Security patches need to go out quickly; bigger version jumps, on the other hand, should go through a test environment first, on a planned schedule. In practice this means a monthly rhythm, with out-of-cycle intervention for critical vulnerabilities.

3. Monitoring

Don't let the customer be the one to tell you the site is down. Basic monitoring checks every minute whether the site is up, tracks response times, error rates, an expiring SSL certificate, and free storage. Without alerting, monitoring is just a nice-looking graph.

4. Security

A firewall in front of the web application, bot protection on forms, strong passwords and two-factor authentication on the admin interface, regular permission reviews — for example when a colleague leaves. The vast majority of attacks aren't targeted: automated scripts search for known vulnerabilities. Following the basics filters these out.

5. Performance

What was fast at launch can slow down after two years of content accumulation. It's worth checking load metrics and real-user search data quarterly, before your visitors notice.

What should a fair operations contract cover?

If you get an operations quote, ask about these points — the differences in the answers reveal what looks cheaper but delivers less:

• Response time. How quickly do they start working on an issue, and does that apply to business hours or 24/7?
• Backup frequency and retention. Daily? For how long back?
• What's included and what's extra. Content changes, new subpages, design changes are typically not operations — clarify how many hours are included.
• Reporting. Do you get a monthly summary of what happened: what updates went out, was there downtime, how's performance.
• Exit. If you switch providers, do you get the source code, the database, and the access credentials. This is the most important question, and the one asked the least.

Whose account is it?

This deserves its own section, because it causes a lot of disputes. The domain, the hosting, the analytics, and the ad accounts should be registered in your name, with you as the owner. The partner should get access, not ownership. This isn't about distrust: if anything happens to the partner, or you simply want to switch, this is what determines whether the transition takes weeks or minutes.

What should you handle yourself, and what should you leave to a partner?

There are a few things no one can do for you: deciding what goes on the site, responding to incoming inquiries, and flagging business changes (a new service, new hours, new prices). Everything else — the server, updates, backups, security, measurement — is typically better handled by someone for whom this is their profession.

You can tell good operations by the fact that nothing happens. If every month is exciting, something is wrong.

A simple checklist

1. Is there a daily backup, and have we actually tested restoring it?
2. Do we get an alert if the site becomes unreachable?
3. When was the last security update?
4. Is the SSL certificate not about to expire, and does it renew automatically?
5. Is there two-factor authentication on the admin accounts?
6. Is the domain registered in our name?
7. Do we know who to call if the site goes down on a weekend?

If you can answer these questions without hesitation, you're in good shape. If not, it's worth sorting out before your next website project — because a new site will run into exactly the same problems.

We include operations with the sites we build, but we'll go through this checklist with you even if we didn't build your site. Get in touch for a health check.