Write the launch checklist before the code

Most launch checklists get written the night before launch, by a tired person, from memory. That’s exactly when you forget the DNS record.

We write ours in the first week of a project, before there’s anything to launch.

Launches fail in boring ways

In years of launching client projects, we’ve almost never seen a launch go wrong because of clever code. It’s nearly always something small and forgettable:

• A DNS record pointing at the old server.
• An email domain that was never verified, so password resets vanish.
• A redirect that loops between www and the bare domain.
• An environment variable that exists on staging but not in production.
• Analytics or error tracking still pointed at the test project.

Each is a five-minute fix. At 2 a.m., with real users arriving, each one feels like a fire.

Why week one

Writing the checklist early changes how the project gets built. When “password reset emails arrive within a minute” is on the list in week one, someone sets up email sending properly in week two instead of in a panic in week ten.

It also turns the checklist into a running test. Every Friday, we tick off whatever already works on staging. By launch week, most of the list is green, and the remaining items are the genuinely hard ones.

What’s on ours

Every project’s list starts from the same base and grows from there:

1. Domains. DNS records staged, TTLs lowered two days ahead, www and the bare domain both resolving.
2. Certificates. TLS working on every hostname, renewing on its own.
3. Email. Sending domain verified, SPF, DKIM and DMARC passing, a real reset email received.
4. Data. Production database migrated, a fresh backup taken and restored once.
5. Errors. Error tracking pointed at production, and a test error seen arriving.
6. Rollback. A written way back, with a named person who can run it.
7. Watch. Someone on call for the first 48 hours, with the dashboards open.

Item six is the one people skip. It’s also the one that turns a bad launch into a short one.

Rehearse it

A week before launch, we run the whole checklist against a copy of production. Same steps, same order, with a timer running.

The rehearsal always finds something. Last time it was a cron job that only existed on the old server. Finding that on a Wednesday afternoon took ten minutes. Finding it after launch would have meant a week of missed invoices.

A launch you’ve rehearsed is a deployment. A launch you haven’t is an experiment.

On the day

By launch day, the checklist is short and the room is quiet. One person reads each item aloud, another confirms it, and Dock handles the release itself, with the previous version one click away.

Most of our launches are uneventful. The client is often a little disappointed by how little happens. We take that as a compliment.

Steal the list

You can copy the seven items above into your own project today. Add the things specific to your app, tick off what already works, and look hard at whatever’s left.

That list is your launch. Everything else is just the date.