Define exit criteria before the final review
Write the criteria while planning the round. Identify the main task the app must support, the data that must survive and the recovery behavior users need when something fails. State what would block release: for example, losing content the app says is saved or preventing a supported user group from signing in. Tie each criterion to a check you can actually perform. Broad goals such as feels polished are difficult to verify consistently.
Separate critical functionality from preferences about layout or future features. Different products have different consequences, so adapt the thresholds instead of copying a generic zero-bug rule. A cosmetic issue might be acceptable with a planned fix, while an unresolved privacy problem needs specialist attention. Name the release decision owner and the person who confirms each check. Written ownership prevents an unresolved problem from falling between product and development teams.
Read the evidence at the build level
Review reports for the specific candidate build. Older failures can inform the review, but a claim that they are fixed needs a retest on the changed version. Compare intended and observed outcomes for the essential journey. Keep reports that required founder assistance separate from unassisted success. If only experienced testers can finish a first-use flow, the evidence may not support releasing it to beginners.
Show the coverage gaps alongside passing results. A missing language, account state or supported device is an unknown, not a pass. Decide whether the gap changes the release decision and assign an action if it does. Be cautious with aggregate scores: several favorable opinions do not cancel a confirmed data-loss defect. Private community ratings can help identify an experience worth investigating, but they are not a substitute for task-level release evidence.
Retest fixes and decide what happens to known issues
For every release-blocking issue, record the fix, the build containing it and the retest outcome. Repeat the original steps and check the adjacent behavior that might have changed. If the issue cannot be reproduced, preserve that uncertainty instead of marking it resolved solely because the developer could not see it. Ask for relevant context and decide what monitoring or further testing is needed.
For issues accepted temporarily, document their consequence, affected users, workaround and responsible owner. Make sure any workaround can be explained honestly to users. Do not accept a problem just because it is inconvenient to fix before a planned announcement. A smaller release can sometimes reduce uncertainty, but it does not excuse broken access, unsafe data handling or misleading purchase behavior. Match the release scope to the confidence your evidence supports.
Choose launch, another round or a pause
A go decision should include the candidate build, checks completed, unresolved items and who accepted the remaining risk. A further-round decision should identify the unanswered question and the participant or device coverage needed. A pause should identify the repairs required before external testing is useful again. Each outcome gives the team a next action. Leaving the beta open without a question can consume support time while teaching very little.
Store readiness remains a separate workstream. TestFlight distribution or a completed Google Play test does not replace the provider's review and release process. Once you launch, keep a plan for support, monitoring and retesting important fixes. Early production behavior may reveal situations the beta did not cover. Describe launch readiness within the scope you actually tested, and update your decision log when new evidence changes that assessment.
Working example
Illustrative release decision: a project organizer has a candidate build with successful retests for sign-in and saved-project recovery. The team still has an unresolved visual issue on a secondary screen and no evidence for one supported language. The release owner records the visual issue with a follow-up owner, but requests a focused language round before expanding access to that audience. A saved-project defect would instead block the main release until repaired and retested. The decision note lists the build and links each conclusion to a report. This is a hypothetical decision framework, not a claim that a real app has met its release criteria or been approved by a store.
Build a private testing briefYour next steps
- Write measurable criteria for the essential journey, saved data, recovery and release-blocking risk.
- Review candidate-build reports and leave missing device, user and language coverage visible.
- Require recorded retests for blocker fixes and assign owners to accepted remaining issues.
- Record a clear launch, further-round or pause decision, then handle store review and post-launch support separately.
Official sources
Sources checked October 3, 2026. Review the current provider documentation before acting on requirements.
Download the free app testing templates
Turn the next test into something useful.
Publish a focused brief on RateMyApp. Credits fund approved private reports; public store reviews are voluntary and unrewarded.
List your app for feedback