Start with one complete journey

A prototype can look finished while individual screens still rely on sample data. Write down one real journey: create an account, perform the core action, leave, and return. Follow the same record through the interface, API and database. Mark every mocked response and manual step. This produces a release checklist grounded in behavior rather than visual completion.

Check who can read and change each record

A hidden button is not a permission boundary. Build a small matrix of roles and actions: customer reads their own order, staff updates an order, administrator changes staff access. Verify both allowed and denied requests at the server boundary. Include a second user account in the review so that cross-account access is tested explicitly.

Make repeated actions safe

Double clicks, timeouts and retries are ordinary conditions. Decide what should happen when an action is submitted twice. A second payment attempt, booking or stock adjustment deserves more care than a repeated profile read. Where the action must happen once, design a stable operation identifier and enforce uniqueness in the system that owns the record.

Rehearse failure, not just success

Disconnect the network during a request. Submit invalid data. Remove an optional integration from the test environment. Confirm that the interface explains what happened, preserves useful input and gives the person a safe next step. Avoid displaying success before the system responsible for the action has confirmed it.

Prepare the production environment

Keep secrets in server-side environment configuration and identify which values are intentionally public. Review migrations, backup and recovery steps, domain configuration and the deployment rollback path. Run the release candidate with production settings; a development server can hide assumptions about caching or build-time configuration.

Define what “ready” means

Separate release blockers from improvements. A broken account boundary is a blocker; a secondary visual refinement may be a follow-up. Record the accepted scope, the checks performed and known limitations. AI tools can accelerate implementation, but this final decision needs an accountable human owner.