# A software launch checklist, step by step

> A software launch checklist for product, quality and go-to-market, plus launch day and what to do after. Copy it, give every line an owner and ship.

A launch fails on small things nobody owned: a missing rollback, a support team that was not told. A checklist, with an owner on every line, catches them before the day.

Web page: https://kansohq.app/guides/software-launch-checklist

Updated: 5 October 2026

## How to use a launch checklist

Treat the list as a set of questions, not a ritual. For each line, name an owner and a date. If a line does not apply, delete it and say why. A checklist that is ticked without being read is worse than none.

## Before launch

### Product

- The scope of the release is frozen and written down.
- Every must-have task is done and its acceptance criteria are met.
- Known bugs are triaged: fixed, or accepted with a reason.

### Quality

- The [test plan](https://kansohq.app/templates/test-plan.md) has been run on the release build, not on a developer’s machine.
- The riskiest areas have been tested twice.
- The rollback steps are written down and someone has tried them.
- Monitoring and alerts cover the new behavior.

### Go to market

- The [release notes](https://kansohq.app/guides/how-to-write-release-notes.md) are written and reviewed.
- Support knows what is changing and where to send questions.
- Documentation and help pages match the release.
- Any announcement is scheduled, with the same date as the release.

## Launch day

1. Confirm who decides go or no-go, and when. Write it in the channel so everyone can see.
2. Run the final checks: build, migrations, configuration and flags.
3. Ship, in the order planned, with the rollback ready.
4. Watch the first signals for an hour: error rates, sign-ups, support messages.
5. Tell the team, then the customers.

## After launch

- Look at the numbers after a day and a week, against the success measure you set.
- Collect what customers and support are saying, and turn it into tasks.
- Hold a [retrospective](https://kansohq.app/guides/how-to-run-a-retrospective.md) while the memory is fresh.
- Move anything unfinished to the next release, on purpose.

## The mistakes that sink launches

- No named person deciding go or no-go.
- A rollback that has never been tried.
- Support finding out from a customer.
- Several risky changes shipped on the same day, so a problem cannot be traced.

## A rollback plan that works

A rollback plan is the answer to “what do we do if this goes wrong?”, written before it does. It should say:

1. What would make us roll back: an error rate, a broken flow, a customer-reported loss.
2. Who decides, and how quickly. In the first hour, a named person should be able to decide alone.
3. The exact steps, in order, that undo the release, including any data changes.
4. What does not roll back. A database change that has already run, an email that has already gone out.
5. How we tell people: the team, support and, if needed, customers.

Then try it on a copy of the real environment. A rollback that has never been run is a hope, not a plan.

## Who needs to know, and when

| Who | What they need | When |
| --- | --- | --- |
| The team | The date, the owner, what is in | When scope is frozen |
| Support | What is changing, what customers will ask, who to escalate to | A few days before |
| Customers | What is new and what to do | On the day, or just before for large changes |
| Leadership | What shipped, and how it is going | After launch, with numbers |

## Sizing a launch

Not every release needs every line. A small fix can ship with a test and a note. A change that moves how customers work needs the whole list, a rollback plan and a briefing for support. Decide which kind it is early, and say so at the top of the checklist, so nobody over- or under-prepares.

## A launch checklist in Kanso

The [launch checklist template](https://kansohq.app/templates/launch-checklist.md) has these lines ready for a doc. For a real launch, build a [release page](https://kansohq.app/product/releases.md) with a Product, a QA and a Go-to-market section: each line has an owner, a due date and a status, and the progress at the top fills as lines are done.

## Questions

### What should be on a software launch checklist?

Product readiness (scope, acceptance criteria, bugs), quality (tests, rollback, monitoring), go-to-market (release notes, support, docs), then launch day steps and what to do after.

### Who should own the launch checklist?

One person owns the list and the go or no-go decision. Each line has its own owner and a date.

### How is a launch checklist different from a release plan?

A release plan covers the whole run up to the date: scope, work and risks. The checklist is the final set of questions that must be answered yes before and on the day.

### When should we hold the go or no-go decision?

Agree the time and the person in advance, and make the decision with the checklist in front of you, usually a day or two before launch and again on the day.

## Keep reading

- [How to plan a software release, step by step](https://kansohq.app/guides/how-to-plan-a-software-release.md): Plan a software release in seven steps: fix the date, freeze the scope, split the work by team, track blockers and decide go or no-go. With a checklist.
- [How to write release notes people read](https://kansohq.app/guides/how-to-write-release-notes.md): Good release notes say what changed and why it matters, in plain words. Learn the structure, a before-and-after example and what to leave out.
- [How to run a retrospective that changes something](https://kansohq.app/guides/how-to-run-a-retrospective.md): A retrospective is only worth it if something changes afterwards. Learn a simple format, how to run it in an hour and how to follow through.
- [Software launch checklist template to copy | Kanso](https://kansohq.app/templates/launch-checklist.md): A software launch checklist template covering product, quality and go-to-market, launch day and after launch. Copy it, or start it in Kanso.
- [Test plan template for software releases | Kanso](https://kansohq.app/templates/test-plan.md): A test plan template with scope, risks, test cases, environments, exit criteria and sign-off. Copy it, or start it as a page in Kanso.
- [Release notes template: what changed and why | Kanso](https://kansohq.app/templates/release-notes.md): A release notes template with a summary, what is new, improved and fixed, known issues and upgrade notes. Copy it, or start it in Kanso.

## Parts of Kanso used

- [Kanso Releases](https://kansohq.app/product/releases.md): A release page gathers the work behind one date into sections, with an owner, a due date and a status on every line.
- [Kanso Boards](https://kansohq.app/product/boards.md): A board for each piece of work. Cards carry a priority, an owner, a due date and the criteria that say when they are done.

[Kanso home, with plans and prices](https://kansohq.app/index.md)