BUILD
What launch day should include
5 min read
A launch is complete when backups have been restored in a test, monitoring alerts a named person, and the client holds every credential — not when the site resolves on the live domain.
Launch day usually gets treated as the finish line, which is why the list of things that only matter afterwards tends to get compressed into the last afternoon.
Most of it takes an hour if it is done before the deadline and takes a week if it is done after an incident. Here is the list worth insisting on.
The things that stop it being broken
These are binary and checkable in minutes, and all of them get missed at least sometimes.
- A valid SSL certificate with automatic renewal confirmed, not just installed
- HTTP redirecting to HTTPS, and one canonical hostname with the other redirecting to it
- Security headers set, including a content security policy that has actually been tested against the live pages
- Redirects from every old URL that had traffic or links, not just the top ten
- robots.txt and the sitemap correct, and the staging site blocked from indexing
- A 404 page that helps, and a 500 page that exists
Backups you have restored
A configured backup is a belief. A restored backup is a fact. Before launch, restore the database and files into a scratch environment and confirm the result works.
Also agree the two numbers that define what the backup is for: how much data you can afford to lose, and how long a restore may take. Those drive frequency and retention, and without them the schedule is arbitrary.
Monitoring that reaches a person
Uptime monitoring from outside the hosting, checking a page that exercises the application rather than a static file that will keep returning 200 after the database has failed.
Then error reporting and certificate expiry alerting, both routed to a named person or a shared inbox that is read. An alert that arrives only in a dashboard nobody opens is the same as no alert, and this is the single most common gap in a handover.
Analytics configured before traffic arrives
Analytics installed the week after launch loses the launch, which is the period everyone will later want to understand. Set it up and verify it is recording before the domain switches.
Same for search console verification and the sitemap submission. Both take minutes and both are much more useful from day one than from day thirty.
The handover that makes it yours
At the end, the client should hold the registrar login, the DNS, the hosting, the repository, and every third-party account the site depends on. Not delegated access that the supplier can revoke — ownership.
Alongside that, a short written document: where everything is hosted, how to deploy, what the backup and restore procedure is, who to contact. Two pages that someone can read in an emergency is worth more than a comprehensive manual nobody opens.
A supplier who is comfortable with this is describing a relationship you can leave. That is worth knowing on launch day rather than during a disagreement.
Questions we get asked
When is the best time to switch the domain over?
Early in a working day, early in the week, when the people who built it are available. Friday afternoon launches are traditional and are the reason weekend incident stories exist. Lower the DNS time-to-live a day or two in advance so a rollback propagates quickly.
Is a soft launch worth it?
For an application, usually yes. Running on the live infrastructure with a small group of real users finds the problems that staging does not, because staging has clean data and patient testers. For a brochure site it adds coordination for little benefit.
What should happen in the first month after launch?
Watch error rates and the search console for crawl problems, confirm the first scheduled backup completed and can be restored, and check that the redirects are being followed rather than producing 404s. Most post-launch problems surface in the first two weeks and are cheap to fix while attention is still on the project.