A working demo answers only part of the launch question
A demo shows that a journey can work under the conditions you chose. Launch preparation asks whether the same promise holds when a customer makes a mistake, a provider is unavailable or two requests arrive together. Across the sampled Reddit discussions, builders repeatedly distinguish shipping a screen from owning the resulting service. Use the five questions below to create a release record: expected behaviour, evidence, unresolved risk and the person responsible.
Can one user access another user’s data?
Test access with at least two accounts and different roles. Changing an identifier in a request should not reveal another customer’s information. Check the server-side decision, not just whether the interface hides a button. Create synthetic data for two separate organisations and repeat the request through the API. Include a removed team member and a logged-out visitor. Retain the allowed result as well as the denied one. The useful output is an access matrix linked to test results, not a screenshot of the login screen.
What happens when a dependency fails?
Payment providers, email services, and external APIs will sometimes return errors or time out. Review the user experience, retry behaviour, and stored state after those failures. A retry should not create a duplicate charge or order. List the state transitions your product promises. For a booking, distinguish reserved, paid, confirmed and cancelled. Record what a customer sees if the payment succeeds but confirmation is delayed. Ask who reconciles the mismatch and how they avoid creating a second booking. Use controlled test data rather than experimenting on customer orders.
Can you recover the data?
A configured backup is only part of the story. Ask when a restore was last exercised, what it recovered, and how the team would handle the gap between the backup and the incident. Run a restore into a separate environment and inspect a representative record plus its attachments. Record the recovery time and the missing-data window you actually observed. A spreadsheet saying “backups enabled” cannot answer those questions. Decide whether the observed result is acceptable for the commitments you make to customers.
Will you notice a broken journey?
Identify the handful of journeys that matter most: signup, payment, data creation, and account recovery. Decide what failure signals the team will monitor and who responds. Avoid logging sensitive values merely to make debugging easier. Start with a small operational checklist: failed signups, unsuccessful payments, stuck jobs and unusual request volume. Set a named response owner and an escalation route. An alert is incomplete until someone knows how to investigate it. Review the signals after the pilot so that noise does not hide the failures that matter.
Can you reverse a release?
Document how you would roll back an application change and what happens if it includes a database migration. The answer should be practical enough for the person responding under pressure. Rehearse the sequence against a staging release, including what happens to records created after a migration. Sometimes the safer response is a forward correction or temporarily disabling a feature. Write the decision criteria down before an incident; rollback should not be an improvised guess about database compatibility.
Turn the answers into a review scope
These questions do not replace a complete assessment. They help you identify the product flows, infrastructure, and evidence that a useful launch review should cover. Put the results in one short launch record with the application revision, environment, test date and open decisions. A limited pilot is reasonable only when its risks are understood. Use the focused permissions and testing guides below for deeper checks, and request an assessment when you need an independent review of the evidence.
Sources & further reading
Reference material for the guidance and examples above. Where included, community discussions provide context rather than verified incident evidence.
Expanded with AI-assisted research. This is an editorial checklist, not a report of a client audit.