Launch readiness planner

How the planner decides

The planner uses one rule, written here so nobody has to guess how it works:

• If any gate is Blocked, the verdict is "Not ready", with the number of blocked gates.
• Otherwise, if any gate is Not started or In progress, the verdict is "Not ready yet", with the number of open gates.
• Only when every gate is Done or Not needed does the verdict say the release can proceed to sign-off.

There is deliberately no score. A percentage suggests that eleven finished gates out of twelve is nearly ready, when the twelfth might be the payment flow. Gates are not equal, so the planner does not add them up. The export groups gates by status, with blocked gates at the top, so the next action is obvious.

The twelve gates

These are the gates the planner lists, in order. They also work as a paper checklist if the planner does not run in your browser.

1. Scope agreed in writing.
2. Test cases written for the key flows.
3. Functional testing finished.
4. Cross-browser and device testing finished.
5. Accessibility checks finished.
6. Security settings checked.
7. Search metadata checked.
8. Performance checked.
9. Content proofread and approved.
10. Blocking defects fixed and retested.
11. Backup and rollback plan ready.
12. Sign-off from the launch owner.

Using "Not needed" honestly

"Not needed" exists because not every release touches everything. A content-only update may not need a performance check. But it is also the easiest way to make a release look ready when it is not. A good rule: anyone marking a gate as not needed should be able to say why in one sentence, and that sentence belongs in the project notes.

Using the launch date

If you enter a planned launch date, the export shows how many days remain. That is useful for a conversation about whether the blocked gates can realistically be cleared in time. If they cannot, the honest options are to move the date, reduce the scope of the release, or launch with known issues and a written plan to fix them. The planner cannot make that call; it only makes the trade-off visible.

From gates to checks

Each gate stands for a group of detailed checks. The QA checklist has 38 of them, grouped in a way that maps onto these gates. If you want someone outside the project to work through the gates with evidence, that is what the pre-launch QA review does.

Running a readiness meeting with the planner

The planner works well as the agenda for a short launch meeting a few days before go-live. A simple format:

1. Before the meeting The launch owner fills in the planner with the current status of each gate and shares the export.
2. Go through blocked gates first For each one, agree who will clear it and by when. If nobody can, say so.
3. Then the open gates Confirm each one has an owner and a realistic finish date before launch.
4. Challenge the "not needed" gates Ask for the one-sentence reason for each. Change the status if the reason does not hold.
5. Decide Launch on the date, move the date, or launch with named known issues and a written fix plan.
6. Record Download the updated plan and file it with the project notes, along with the decision.

Twenty minutes can be enough for a small site. The point is not the meeting itself but the shared, written view of what is and is not finished.

Gates for larger releases

Twelve gates suit a small or medium website. A larger release may need more: data migration checked, third-party integrations signed off, staff trained on a new admin area, legal review of new terms, or communications planned for customers. Write the extra gates into your own checklist alongside the planner's export; the same rule applies to them. Anything blocked or unfinished means not ready.

When the verdict is "not ready"

A "not ready" verdict is information, not failure. It tells you which gates need work and gives you a list to plan from. Sort the blocked gates by how long they will take to clear, check whether any can be cleared by reducing scope rather than adding effort, and agree a new date or a known-issue plan in writing. Then run the planner again when the status changes, so the next verdict reflects the real position.

Privacy

The planner runs in your browser. Statuses, names and dates stay on your device and disappear when the tab closes. Download the plan if you want a record.