In this guide
A go / no-go checklist turns "feels ready" into a decision you can explain. Each criterion has an owner, a threshold and evidence. If you are a solo developer, you are every owner, and writing it down still stops you from skipping the awkward ones.
Copy-paste template
RELEASE DECISION: [App], version [x.y.z] (build [n]), date [date]
Decision maker: [name]
| # | Criterion | Owner | Evidence (link / note) | Go? |
|---|---------------------------------------------|--------|------------------------|-----|
| 1 | No open crash or data-loss bugs in the build| [name] | [issue list, crash log]| Y/N |
| 2 | Core flows pass on the release build | [name] | [test notes, date] | Y/N |
| 3 | Install and update from the previous version| [name] | [device, versions] | Y/N |
| 4 | Known issues documented and accepted | [name] | [known issues list] | Y/N |
| 5 | Sign-in, payments, permissions work | [name] | [test notes] | Y/N |
| 6 | Store listing, notes and screenshots match | [name] | [draft link] | Y/N |
| 7 | Rollback or halt plan exists | [name] | [plan link] | Y/N |
| 8 | Someone can watch crashes after release | [name] | [who, until when] | Y/N |
Any "N" on 1-3 or 5 = NO-GO unless the decision maker writes down why.
Decision: GO / NO-GO / GO with conditions: [conditions]
Example (invented)
RELEASE DECISION: Pocket Budget, 1.2.0 (build 57), 2026-10-17
Decision maker: Sam
1 Crash/data-loss: none open - issue list checked 10:15 - Y
2 Core flows: add, edit, delete entry pass on release build - Y
3 Update from 1.1.4: tested on two devices - Y
4 Known issues: CSV export slow, accepted - Y
5 Sign-in/permissions: notification permission denied path not tested - N
...
Decision: GO with conditions: test the denied-permission path before submitting.
How to adapt it
- Change the criteria to your app. An offline-first app needs an offline row; an app with in-app purchases needs a purchase row.
- Write thresholds as yes/no. "Looks stable" is not a criterion. "No open crash bugs on the release build" is.
- Test the release build, not the debug build. Behavior can differ, so evidence from the wrong artifact does not count.
- Name the decision maker once. Voting groups drift. One person decides after hearing the owners.
- Keep the filled-in copy. Next release you can see what you accepted last time.
Related: hotfix checklist, rollback and halt plan, and the hub mobile app testing checklists.
Need testers on the release build before you decide? Start free.