A product launch checklist beyond “the build passed”

Walk through the promise as a new user

Open the production URL in a clean browser session. Follow the same route a customer will take: landing page, sign-up or sign-in, project creation, the core task and its result. Use a clearly identified test account and disposable test data. Do not silently test destructive actions against a real customer's project.

For the handoff example, upload or select a deliverable, share it with the intended client, make a decision and retrieve the record. Reload the page and sign in again. A success notification that disappears without saving the result is a failed test, even if no error appeared on screen.

Check the boundaries, not just the happy path

Try an expired link, an account without permission, an empty input and an interrupted request. Confirm the interface tells the user what happened and what to do next. Submit the same action twice where that could happen naturally; the product should not create an unintended duplicate or charge.

If payments are part of this release, test the configured checkout, cancellation, failed-payment and access paths using the provider's test environment before an explicitly approved live check. A payment button alone does not prove billing works. Keep payment credentials and test details out of screenshots and shared documents.

• Access: one user cannot retrieve another user's private project or file.
• Persistence: the result survives reload and a new session.
• Recovery: a failed operation can be retried without losing the draft.
• Repetition: repeated submission has the intended effect.
• Files: links open the expected version, not a stale or unauthorized object.

Know how you will notice a failure

Make a safe test operation fail and follow the result. Does the user get a useful message? Does the person responsible receive an alert? Can they find the failed operation without asking the user to repeat everything? A green homepage monitor will not answer these questions about project creation or file access.

Watch a mobile user attempt the same task. Check readable text, reachable controls, visible progress and error messages that preserve their work. Record blockers with the action, expected result, observed result and environment. “It feels broken” is a useful signal, but a precise reproduction makes the repair much faster.

Keep a release record you can challenge

Record the tested URL, version or deployment identifier, date, test account role and result of the core journey. Include screenshots where they clarify a result, but do not treat screenshots as proof that data persisted. Preserve failures as well as passes, and retest the affected path after a change.

In Symbiont, inspect the project files and release information separately. A complete set of artifacts may be ready for review while release evidence is still missing. Ask what check established the claimed outcome. Launch a bounded pilot when its important checks pass and you can support the users you invite; expand after observing actual use.