Freeze scope, not learning
A release candidate needs a defined scope so the team can test a stable target. New observations should still be recorded, but only issues that threaten the product promise, safety, compliance or recovery should enter the release at this stage.
Keep one decision log for accepted risk. “Known issue” is not a plan unless it has impact, owner, mitigation and a date for review.
| Level | Example impact | Gate action | Evidence required to close |
|---|---|---|---|
| Stop-ship | Core journey fails, data is exposed or required control is unavailable | Pause the candidate and assign an owner | Fix verified on affected paths plus a regression check |
| High | Important journey is unreliable with no clear recovery | Resolve before release or document an explicit risk decision | Reproduction result, mitigation and accountable approval |
| Follow-up | Limited issue with a clear workaround and no material policy impact | Record for the next planned update | Owner, scope, workaround and review date |
Test complete journeys from a clean state
Start with a fresh installation and a device that has no developer shortcuts. Complete onboarding, the main value journey, purchase or account flows, support access and sign-out or deletion. Then test an upgrade from the previous public version.
Repeat critical flows with denied permissions, interrupted network access, low storage, large text and a changed device clock. The goal is not to simulate every possible failure, but to verify that the product remains understandable when normal assumptions break.
Review accessibility as interaction quality
Check focus order, accessible names, contrast, text scaling, motion preferences and touch targets. Listen to the critical flow with a screen reader rather than relying only on automated findings.
Accessibility testing often reveals broader product problems: ambiguous labels, hidden state, actions that rely only on colour and layouts that collapse when content grows.
Reconcile privacy and account controls
Compare actual network traffic and SDK configuration with the privacy policy and store declarations. Verify that consent choices change behaviour, permission explanations match use, and account deletion can be reached both in the app and through the required web resource when applicable.
Make sure support can identify a deletion request without asking for unnecessary information. Record how long completion normally takes and which records must be retained for a legitimate reason.
Treat the store listing as part of the release
Screenshots must represent the submitted product. Descriptions, age rating, data disclosures, subscription terms, support links and review notes should be checked against the exact build. Provide a working reviewer account when functionality is restricted.
Open every public URL from a logged-out browser. A privacy or support link that works only for the development team is still broken for review.
Prepare observation and rollback
Before release, confirm crash reporting, service health, support ownership and a staged rollout plan. Define which signal pauses the rollout and who has authority to decide. For backend changes, ensure old application versions continue to work during adoption.
Write the first-day checklist before pressing release. Operational calm is designed in advance; it does not appear because the binary passed review.
Field example: a policy page can load while its support path fails
During an AppMe website audit on October 16, 2026, the sitemap contained 43 URLs and the link audit visited 48 distinct internal paths. Two linked paths returned 404: /petme-account-deletion and /cdn-cgi/l/email-protection. The current account-deletion page at /policies/petme-account-deletion itself returned 200. This is a concrete example of why checking only the store’s destination URL misses a broken journey.
The deletion page still advertised the older root-level address. Some imported policies also contained email links pointing to Cloudflare’s email-protection endpoint rather than a usable contact action. That endpoint had been carried over with archived content. A document could therefore look complete while the next action needed by the reader failed.
To reproduce this class of defect, fetch the public destination while signed out, collect its links and follow each support and deletion action. Record the original URL, any redirect and the final status. For an email action, inspect the mailto recipient and subject rather than treating a successful HTTP response as the acceptance criterion. A web crawler cannot verify that a mailbox is monitored or that a deletion request is completed.
A durable repair needs both current links in the document and a redirect for the older public URL. Store listings, help articles and user bookmarks can continue to carry the previous address. Keep the original policy version before repairing imported content, and rerun the same checks against the deployed site because its database can differ from the developer’s local copy.
These observations establish broken website paths. They do not establish that an application’s deletion backend is defective, that its support mailbox is unreachable, or that a specific advertising-policy decision was caused by those paths. Verify those separate outcomes with the relevant system and account evidence.
| Step | Acceptance condition | Limit of the check |
|---|---|---|
| Open the store-listed URL | Public page loads without an administrator session | Does not verify the instructions against the app |
| Follow a previous public URL | Redirect reaches the current document | Does not update an external store listing |
| Activate the email link | Mailto recipient and subject are intact | Does not prove mailbox delivery or response |
| Submit a controlled test request | Authorized account request reaches the responsible team | Requires separate operational verification |
Primary references
Store requirements change. These official sources should be checked again before a release decision.