Release Go/No-Go Decision Framework for Mobile Teams
The go/no-go decision for a mobile release is frequently informal, inconsistent, and unduly influenced by schedule pressure. This framework provides a structured, repeatable process for release sign-off that makes the quality evidence explicit, defines escalation paths for borderline decisions, and creates an audit trail for post-release incident review.
The four quality gates
A release go/no-go decision should be based on four quality gates, assessed in sequence. A gate failure at any level is a no-go signal unless explicitly overridden by authorised stakeholders with documented risk acceptance.
- Gate 1 — Regression: no P1 or P2 defects open against the release candidate build. P3 defects must be triaged and accepted or deferred with documented owner.
- Gate 2 — Coverage: the device matrix specified in the test plan has been executed in full, or a documented matrix reduction has been approved with residual risk acceptance.
- Gate 3 — Performance: crash-free session rate on the release candidate meets or exceeds the target (typically ≥99.5% for consumer apps). Cold start time within acceptable bounds.
- Gate 4 — Compliance: App Store / Google Play pre-submission review complete, no open submission-blocking findings. For regulated verticals, compliance evidence package complete.
Defect severity classification
Consistent severity classification is the prerequisite for a meaningful go/no-go process. Without agreed severity criteria, the gate cannot be assessed objectively.
- P1 — Release blocker: crash, data loss, security vulnerability, payment failure, or user unable to complete a primary journey on any supported device/OS. Go/no-go: NO GO.
- P2 — Release risk: significant functional failure affecting a primary journey on a subset of supported devices; accessible feature broken for users with assistive technology; compliance finding. Go/no-go: escalation required.
- P3 — Non-blocking: UI defect, cosmetic issue, performance degradation within tolerance, edge-case failure on unsupported or rare device configuration. Go/no-go: documented deferral acceptable.
- P4 — Enhancement: improvement opportunity, minor usability issue. Deferred to backlog without impacting go/no-go.
Escalation path for borderline decisions
P2 defects require an escalation process rather than a binary go/no-go rule. The escalation process ensures that risk acceptance is explicit and attributed.
- Step 1: QA lead documents the P2 defect, affected device/OS scope, estimated percentage of users affected, and available workaround (if any)
- Step 2: Product and engineering leads review the documented risk
- Step 3: If both leads accept the risk, they sign off with documented rationale and a post-release monitoring commitment (e.g., 'monitor crash rate for 24h post-release, rollback if rate exceeds X%')
- Step 4: Escalation to VP/Director if the P2 affects a revenue-critical journey (payment, primary conversion flow) or a regulated feature (health data, financial transaction)
- Do not proceed on P1 defects without explicit C-level sign-off and a documented rollback plan
Post-release monitoring requirements
Go/no-go is not the end of the quality process. A release plan is incomplete without a defined post-release monitoring window and rollback trigger.
- Monitor crash-free session rate for the first 2 hours post-release (use Crashlytics / Sentry real-time view)
- Define a rollback trigger: if crash rate exceeds [X]% within 2 hours, initiate rollback or expedited hotfix
- For staged rollouts (Google Play): hold at 10% rollout for 2 hours minimum before expanding; monitor crash rate at each expansion stage
- Complete a 24-hour post-mortem if any P1 defect is found in production: what gate failed, why was it not caught, what process change prevents recurrence
Frequently asked questions
The go/no-go decision should have a single accountable owner per release, typically the Product Manager or Release Manager. The QA lead provides the quality evidence and the gate assessment; the decision authority rests with the Product Manager. Engineering leadership is consulted for technical risk assessment. This structure keeps the decision accountable and prevents it from defaulting to whoever is least willing to delay a release.
If P2 defects are present at every release, the issue is upstream: either the defect severity classification is calibrated too low (P3 issues being rated P2) or the quality gates are not catching issues early enough in the cycle. The fix is not to relax the go/no-go criteria but to shift detection earlier. A CI/CD smoke gate that catches regression defects at the PR stage typically reduces the P2 backlog at release candidate stage significantly within two to three sprint cycles.
Need more detail?
Our team can provide vertical-specific data, custom analysis, or a live walkthrough of any resource on this page.