Walk through the customer's first session
Create a fresh account in the environment you plan to release. Follow verification or provider callbacks, reload the application, update a profile, and sign out. Repeat the journey on a narrow screen using a keyboard. Your normal development session can hide missing setup steps and stale state.
Check the messages that explain what to do next. An empty screen should offer a useful action. A failed request should explain how to retry without implying that work succeeded. Use the actual product's language in those messages, and make sure account and support links reach real destinations.
- Fresh account creation and session restoration work.
- Sign-out revokes access and clears the previous user's presentation.
- Empty, loading, and error states remain understandable on mobile.
Verify the boundaries with real dependencies
Use two independent accounts to verify ownership. Try retrieving and modifying one account's record from the other account, including task status and recovery URLs. Check paid access at the server action boundary, not only by hiding a button in the interface.
Exercise the billing lifecycle in a sandbox and inspect the persisted entitlement after events are processed. Confirm that repeated events are safe and inactive access blocks paid work. For background execution, test a failed dispatch and a failed completion message separately. Neither should cause a silent duplicate generation.
- Cross-workspace reads and writes are rejected.
- Billing events update server-owned access state.
- Task recovery and independent delivery failures have been exercised.
Prepare for the first failure
Make sure someone can find an error, connect it to the relevant task, and help the user recover without exposing provider secrets. Confirm which logs and audit records exist, how long you retain them, and how an operator gets access to them.
Keep a release record of what was tested and what remains unverified. Include the build revision, target environment, and any external acceptance checks. Treat backups and restoration as an operational exercise: having a backup configured is different from knowing that the data you need can be restored. Launch when you can support the flow you are offering, then expand it deliberately.