Who Presses the Button When Your Website Goes Live?

Every website change ends the same way: somebody puts it live. A new page, a fixed bug, a whole rebuild — at some point a human being presses the button, holds their breath, and hopes the site still works afterwards.

If that sentence made you slightly nervous, your delivery process is running on courage. Here's how to replace the courage with a process.

The Friday-afternoon deploy

The scene is familiar to anyone who's been near a website project. The change is finished late in the day. One person knows the exact steps — which files, which order, which checkbox in the hosting panel. They do it from memory, it mostly works, and everyone agrees to "test it properly on Monday." Monday brings a customer report about the thing nobody checked.

Nothing here is anyone's fault. When releasing depends on memory, timing and one person's availability, failures aren't a surprise — they're the schedule. The fix isn't more careful people. It's fewer things left to memory. If that sounds familiar, start with why manual deployments keep going wrong before buying a bigger tool.

What a calm release looks like

A repeatable release has four qualities, and none of them requires exotic tools:

1. The steps are written down, then automated. The path from finished change to live site is the same every time — reviewed, built, checked, then published — not re-improvised per release. Automation doesn't make it fancy; it makes it identical.
2. Checks run before customers see anything. Automated checks on the critical journeys, a look at performance, a review by a second pair of eyes. The release waits for the checks; the checks don't chase the release.
3. Going back is planned, not improvised. Every release has a way back — the previous version restorable, the data safe, somebody authorised to call it. Rollback planning feels pessimistic right up until the afternoon it saves you.
4. Everyone knows who owns what. Who approves a release, who watches it go out, who gets called if it misbehaves. A release nobody owns is a release nobody can stop.

Notice what's missing from that list: speed. Repeatable delivery sometimes ships daily and sometimes ships monthly — the point is that each release is deliberate and recoverable, whatever the rhythm. Frequency without the rest is just faster accidents.

The questions that reveal the truth

If you run a business with a website, you may never have thought about any of this — it lived with your developer or agency, invisibly. These questions surface it:

• Could anyone on the team release safely, or only one person? If the answer is one person, you don't have a process — you have a dependency. Holidays, illness and resignations all become release risks.
• How long would it take to undo the last change? "A few minutes, we've done it before" is a good answer. A long silence is the finding.
• Where do changes wait before going live? There should be a staging or preview step between "finished" and "public" — somewhere the change can be checked in realistic conditions. If finished work goes straight to the live site, every release is an experiment on your customers.
• What changed in the last release? If nobody can say precisely, there's no review trail — and no way to know which change caused the problem you're now debugging.

For a rebuild or a major refresh, these questions matter doubly: big launches concentrate months of changes into one nervous afternoon. Smaller, reviewable releases with a rehearsed way back turn that afternoon into just another day. If the team is not ready for full automation yet, a release checklist may be the right first step.

Delivery, environments and infrastructure belong together

Releases don't happen in a vacuum. The change moves through environments — preview, staging, production — each with its own configuration, access and data. When those environments drift apart ("it worked on staging" is the classic symptom), releases become unpredictable no matter how careful the steps are. That is why staging and production need clear boundaries.

That's why delivery work and infrastructure work travel together: defined environments, controlled configuration, and monitoring that tells you something changed before your customers do. Just make sure the monitoring has an owner, because monitoring is not the same as someone watching. And it connects forward too — deciding what ships first is easier when shipping itself is cheap and safe, because a small release stops feeling like a gamble.

Somebody will always press the button. The goal is a setup where pressing it is boring — reviewed, checked, reversible, and owned. Boring releases are the ones customers never notice, which is exactly the point.