The release checklist for small teams: twelve boxes between “green build” and “shipped”

A release checklist is not paperwork; it is the memory of your last three bad Fridays, written down while the pain was fresh. Every box on a good one exists because somebody once shipped without it: the migration that could not be un-run, the flag that never got set for gradual rollout, the Friday 5pm release with no note and no owner. For a team under twenty, the checklist is twelve boxes, most releases check nine of them in five minutes, and the point is that the three that apply are the three that would have hurt.

This note gives the checklist itself, the risk-class shortcut that keeps it fast, the five traps that turn checklists into rubber stamps, and a one-afternoon rollout. It sits between the change review that approves the release and the release notes the customer reads.

1. The twelve boxes

• 1. Rollback is named and rehearsed. The exact undo — revert commit, down-migration, feature-flag default — written in the release doc, not in someone's memory. An untested rollback is a wish (the same law the rollback checklist exists to enforce).
• 2. Migrations are reversible — or explicitly marked one-way, with the reason written down. A one-way migration is a decision, not an accident.
• 3. Feature flags set for anything user-visible. Default off, rollout plan says who sees it first, kill switch confirmed to work.
• 4. Risk class labeled per the change review: data, auth, money, or normal. The label decides how many of the remaining boxes are load-bearing.
• 5. Tests green on a production-like build — not just on the laptop. Config drift between staging and production is where “but it worked in staging” is born.
• 6. Database backup is fresh and its restore was tested recently — the release that touches data is the one that will need it.
• 7. Monitoring covers the change. New queue? New endpoint? If it cannot be observed, it cannot be rolled back on evidence — the golden signals need a row for it.
• 8. Timing chosen on purpose. Not Friday 4:55pm by default; the window matches the blast radius, and anyone on call knows the release is coming.
• 9. Comms ready before the deploy: the release notes drafted, and if the release touches customers in real time, the status page template is warm.
• 10. One person owns the ship. A name, not “the team.” If it goes wrong at 17:40, the decision-maker is named on the checklist.
• 11. The decision to abort is pre-made: the exact signal (error rate, queue lag, support ticket count) that aborts the rollout — agreed before, so nobody has to argue thresholds mid-incident.
• 12. Post-ship watch exists: who watches the dashboards for the first 30 minutes, and what happens at the end of it (ship closed, or incident opened).

2. The shortcut: most releases check nine boxes in five minutes

The checklist would die if every typo fix needed twelve signatures. The risk class from the change review sets the depth: Class 4 (no data, no auth, no money) boxes 1, 5, 8, 10 — ninety seconds, ship. Class 1–3 gets the full twelve, in writing, attached to the release. The shortcut is what keeps the long form honest: a checklist that costs the same for everything filters nothing, and reviewers learn to skim.

Timing rule of thumb: data and auth changes ship early in the day, never last-thing Friday; the whole point of box 8 is that someone chooses the window instead of inheriting one.

3. Five traps

The checklist as memory test. If the boxes live in someone's head, the checklist is that person, and it does not scale past their vacation. Written, versioned with the repo, improved the week after every bad release.

Checkbox theater. Twenty boxes ticked in thirty seconds is not a review; it is a signature. If a box cannot actually be checked (nobody knows the rollback), the honest mark is “not done” — and the release waits or the risk is accepted out loud, by a name, not by default.

Checklists that never change. A checklist frozen since last year is a fossil. Every incident post-mortem donates one candidate box; the checklist accepts at most one new box per month, or it bloats into noise.

The same depth for every release. Twelve boxes for a typo fix teaches the team that checklists are rituals — and then the one release that needed all twelve gets a skimmed one.

Checklist as substitute for rehearsal. Ticking “rollback rehearsed” is not the rehearsal. The box marks that the rehearsal happened — recently, on something production-like — not that someone believes it would work.

4. Worked example

A ten-person project-management SaaS ships weekly, no checklist. The quarter's wounds, in order: a migration that added a NOT NULL column with no down-path (recovery: 7 hours and an emergency data backfill), a billing change that shipped to everyone at once (a hundred support tickets, half of them “what changed?”), and a Friday release where the on-call learned about the deploy from a customer.

They adopt the twelve boxes in one afternoon, attached to the PR template. The next month: the migration that could not be reversed is caught at box 2 and rewritten as two steps; the billing change ships behind a flag to 5% of accounts, and box 8's abort signal (charge-failure rate over 1%) fires once — the flag flips back in four minutes, one ticket total; box 9 means the “what changed” tickets stop arriving because the notes page answers before the question does. Total ceremony per normal release: five minutes for four boxes. The counter-example is their own previous attempt at “release discipline”: a forty-item checklist in a wiki nobody opened, which is why the migration walked through it.

5. Metrics (for the metric itself)

• Every release attaches the checklist; Class 4 shows four boxes, Class 1–3 shows twelve — the depth is visible, not assumed.
• Zero one-way migrations without a written reason.
• Abort signals pre-agreed for every flagged release; flags flipped by signal, not by debate.
• The checklist itself changes at most once a month, and every change cites the release that taught it.
• Time-to-complete for a normal release: minutes. If checklist time grows, boxes have become theater.

From the HIVE80lab kit

• The First 30 Minutes — free incident quick-start
• Ops Starter Kit — incident response for small teams — $14
• Ops Starter Kit Vol. 2 — advanced incident response & communications — $27
• Ops Mega Bundle — all 5 kits in one download — $49

Related: the change advisory board template decides which releases need the full twelve, the deployment rollback checklist is box 1 made real, and the release notes template is box 9 customer-facing.

Related: the hotfix process checklist covers the emergency end of the same pipeline — the eight checks that keep a Friday-night deploy fast but not reckless.the post-deploy verification checklist owns the ten minutes after the deploy button — book them as a box, not a hope.