The launch checklist nobody sends you

Launches fail quietly

Most of what goes wrong at launch does not throw an error. The site loads, the pages render, and something underneath is not doing its job. Nobody notices for weeks, and by then the traffic that mattered has been and gone.

Here is what we check before we call a site live, and why each one earned its place.

Mail authentication, before anything sends

A domain that sends mail needs three DNS records: SPF, DKIM, and DMARC. Without them, transactional mail from your own domain lands in spam or nowhere.

The one that catches people is the interaction between them. Point your MX records at one provider and your SPF record at another and you have a domain that receives mail perfectly well and cannot send it credibly. We check that SPF names the service that is actually sending today, not the one that was sending last quarter.

Backups, with a restore you have actually done

An automated backup nobody has restored from is a hypothesis. The check is not whether backups run. It is whether somebody has taken one, restored it somewhere else, and looked at the data.

This gets more important the moment a system holds invoices, payments, or client history rather than marketing copy.

Security headers on the response, not in the config

A Content Security Policy in a config file is a plan. A Content Security Policy on the response is a policy. We fetch the deployed site and read the headers back, because build-time configuration reaches production through several layers and any of them can drop it.

Analytics that are actually recording

This one is quiet in an unusual way. An analytics script can load, define its global, log nothing you would notice, and record not a single page view, because the beacon goes to a different host from the script and the policy above allows only one of the two.

The check is not that the script tag is present. It is that a page view arrives in the dashboard.

The sitemap a crawler actually receives

Ask for the URL your robots.txt advertises, and read what comes back. A sitemap route that redirects, or returns HTML, or splits into an index for a site with one language, is a sitemap a crawler has to work to use.

Every outbound link you published

Sites link to products, subdomains, and partner pages that were live when the copy was written. We fetch all of them. A link to a subdomain with no DNS is worse than no link, especially on the page asking somebody to buy something.

The form, end to end, with a real message

Not a unit test. Fill in the form on the deployed site, send it, and confirm it arrives where a human will read it.

A contact form that shows a success message and drops the enquiry is the most expensive bug a marketing site can have, because the sender believes they have reached you and stops trying. You never find out. It is the one failure that costs revenue without producing a single error log.

Why we automate most of it

Everything above except the backup restore and the real enquiry runs as a script against the deployed URL. Around fifty checks, a couple of minutes, and it runs after every deploy rather than once on launch day.

A checklist in a document is a thing somebody remembers to read. A checklist the deploy runs is a thing that gets read on the day everybody is in a hurry, which is the day it matters.