Turning a launch into a repeatable process

A repeatable launch is not something you sit down and author from memory. It is the residue of a launch you recorded while it was happening. Run the next site with a blank file open beside you, write down every action as you take it, then spend twenty minutes turning that raw log into a numbered procedure. The rest of this article is about keeping that file honest once it exists.

Why ad hoc stops working around the third site

One or two launches fit in your head, and the gaps get covered because you are still looking at the site daily. Past that, three things break together. The sites become almost but not quite alike, so the differences stop being obvious. The gaps between launches stretch to weeks, so recall gets worse. And you want someone else to take parts of it, at which point "you just know what comes next" has no value at all. The failures that follow are rarely dramatic: an old redirect map never applied, a mail record left pointing at the previous host, a staging block left switched on for a fortnight. Each one is a step somebody has done correctly a dozen times and skipped once.

Capture during, not after

• Log the action, the value you typed and the time. Values are what memory loses first.
• Log what went wrong and how you unstuck it. Those become the "if not" branches.
• Log waits, with the time they actually took rather than the time you expected.
• Do not tidy while you work. A messy live log beats a neat Friday reconstruction.

Separate the fixed steps from the judgement calls

Every step in your log is one of two kinds, and mixing them is what makes a procedure feel unusable. Mark each one before you file it.

Fixed steps are the ones you can delegate, script or batch. Judgement steps are where placement, timing and risk get decided, so keep them short and visible. If you have made the same call eight times running, promote the step to fixed and record the default.

Give every step a done test

The usual defect in a homemade procedure is steps that describe an action but never say how you know it worked. "Update DNS" gets assumed done the moment you click save. Write a check that produces an observable result instead, so a step is ticked on evidence rather than on feeling.

step 14  repoint the domain at the new account
  kind   fixed
  do     replace both authoritative name servers at the registrar
  done   dig +short NS example.com returns both new hosts, from two
         separate resolvers, not just the one on your desk
  if not registrar lock is on, or the change is still queued;
         recheck in 30 minutes before touching anything else

The format itself

One plain text or Markdown file per launch type, kept wherever your team already edits things, with a version number and date at the top. Numbered steps, each carrying the four fields above. No screenshots, because panels get redesigned and screenshots quietly lie. Copy the file per launch and tick the copy, so the master stays clean and each site keeps its own run log.

Versioning when something changes

launch-standard.md   v7   2026-05-02
  v7  add: check mail routing before the DNS switch (missed on site 41)
  v6  drop: manual sitemap ping, endpoint retired upstream
  v5  split step 9 into fixed and judgement halves

Amend the procedure the same day a launch surprises you, while you still remember why. One line for what changed and what prompted it. A change log that names the incident is what stops a future you deleting a step that looks pointless. Companion pieces under launch playbooks cover ordering, many sites at once and handover; for a move rather than a fresh build, pair this with moving in.