How to use it
- 01
Name the decision maker
Write down the one person who will say go or no-go. Shared responsibility for a launch tends to mean the decision is made by the calendar, and the calendar always says go.
- 02
Mark from evidence
Set a line to passed only when someone from the business has watched it work or read the result. Told that it works is open. Use not applicable only where the line truly has no meaning for this system.
- 03
Sort the open lines
Every open line goes into one of two boxes: it blocks the launch, or it is accepted with an owner and a date. A line in neither box is a risk nobody has taken responsibility for.
- 04
Record the decision
Choose go, go with listed issues or postpone, and export the record. Postponing by a few days over a real blocker is forgotten quickly. Launching over it is not.
What a launch decision should be based on
Developers test that what they built works. Acceptance asks whether the organization can run on it from tomorrow, and that takes evidence in four areas beyond the feature list.
| Part | What it settles | Why it matters |
|---|---|---|
| Function | Workflows, exceptions, permissions, messages, integrations | Most launch failures are an exception nobody walked through |
| Data | Reconciled migration, tested restore, clean production | Wrong or unrecoverable data is the hardest fault to undo |
| Quality | Speed, accessibility, security, load, monitoring | Decides whether it stays usable under real conditions |
| Readiness | Training, support, runbook, rollback, launch sequence | A working system still fails if nobody knows how to run it |
| Decision | Blockers, accepted issues and the outcome | Puts responsibility for each open line on a named person |
A worked example
A lift service company decides not to launch on Monday
The example is an invented lift maintenance company a few days from launch. Load it to see the record. Most lines pass, and the decision is still to postpone, for two specific reasons.
- PassedMain workflows, migration, permissions, training and the rollback plan are all marked passed on evidence the planners saw.
- BlockersNobody has ever restored a backup, and reassigning a job with reserved parts fails. The second happens most weeks in real life.
- AcceptedA missing monthly report and two accessibility findings are accepted by the operations director, each with an owner and a date.
The launch moves by one week. The record shows exactly why, which makes the delay easy to explain and gives the developers a short, unambiguous list.
What this tool does not do
The checklist records an acceptance. It does not perform the tests behind it.
- It cannot verify that a line marked passed was really tested. That depends on who marks it.
- The lines are general. Add your own for anything specific to your system or sector.
- It is not a regulatory sign-off. Where approvals are required by law, they have their own process.
- The record is kept only in this browser until you export it.
What to do with the finished document
Send the record to everyone affected by the launch, so that the decision and its reasons are known. If you would like an independent acceptance review before a release, send us the record and the date. Send it through the contact page or book a 30-minute call and bring it along.
Common questions
What is launch acceptance?
It is the point at which the organization that will use a system confirms it is ready to go live, on evidence it has seen. It differs from developer testing, which checks that features work as built. Acceptance checks that the business can operate: real workflows, real data, trained people and a plan for when something fails.
Who should fill in the acceptance checklist?
The people who will run and use the system, with the developers supporting them. Each area is best marked by whoever is responsible for it afterwards: operations for workflows, finance for figures, IT for backups and access. The development company should not be the one to declare its own work accepted.
Can we launch with open lines?
Yes, if each open line is understood, minor and accepted in writing by someone with the authority to accept it, with an owner and a date for the fix. Decide beforehand what always blocks a launch: anything that loses data, takes the wrong money, breaks a legal requirement or stops a core workflow.
How is this different from the ecommerce launch checklist?
The principle is the same and the lines differ. An online store has payments, tax, delivery and search visibility to check, which our ecommerce launch guide covers. This checklist is for business software in general, where workflows, permissions, migrated data and staff readiness carry the weight.