Before launching an AI-built app, verify the complete user journey on the real domain with a clean session. Check domain routing, form delivery, authentication, data permissions, and payments independently. Mark a check complete only when you have observed the expected result; a generated feature or green UI message is not sufficient evidence.
Key takeaways
- Test the deployed system rather than only the builder preview.
- Use ordinary accounts to test permissions and recovery.
- Confirm actual delivery and persisted data behind success messages.
- Test payment events and retries as well as checkout screens.
Domain and deployment
- The production hostname resolves over HTTPS without certificate warnings.
- The production build succeeds from the documented repository state.
- Important routes load when opened directly and when refreshed.
- A nonexistent route returns an appropriate 404 response.
- Production environment settings are present and secrets remain outside browser assets.
- You know how to restore a previous deployment if the release fails.
For static hosting, verify that the host supports your exported paths and not-found behavior. For an app requiring server endpoints, confirm that those endpoints actually exist in the deployed runtime; static files cannot execute server-side payment logic by themselves.
Forms and inquiries
Submit each form with valid input and with missing required fields. Confirm where a valid submission is stored or delivered. Check that the recipient address is operational, and that the user can recover from a delivery failure without losing their message.
If the form opens the user’s email application, label that action accurately. It is not an automatic form submission, and delivery still depends on the user sending the email. Avoid collecting passwords or production credentials in an inquiry form.
Authentication and permissions
- A new ordinary user can register, confirm their email, and log in on the live domain.
- Password recovery returns to the intended application URL.
- Session refresh and signout behave correctly.
- An anonymous visitor cannot access a protected action.
- Account B cannot read, update, or delete account A’s private records.
- Database policies and server-side authorization match the intended ownership model.
Supabase RLS can enforce row-level access, but policies must be reviewed for the specific operations and roles. A hidden button does not protect the underlying request.
Data and core behavior
Create a record, refresh the page, and retrieve it in a later session. Change it and confirm the change persists. Test an empty state, invalid input, and a failed request. Check that the product does not report success before the required operation has succeeded.
Review whether duplicate clicks or retries create duplicate records. Define how deletion works and verify that users cannot modify fields or records they should not control. The correct checks depend on the product: a public portfolio and a private customer portal do not share the same permission model.
Payments and paid access
Verify the intended Stripe mode, products, prices, and production URLs. Complete a supported test flow before enabling real transactions. Review webhook signature verification and the state change that grants access. A visit to a success URL alone must not grant a paid entitlement.
Replay relevant events to check duplicate handling. Inspect failed deliveries and confirm the handler does not depend on a fixed event order. Record how cancellations, refunds, and failed renewals affect access when those behaviors are part of your offer.
Search, accessibility, and handover
Give public pages distinct titles, descriptions, and canonical URLs. Check that useful text is present in the initial HTML, internal links work, and the sitemap lists public canonical pages. Keep private or account-specific pages out of public discovery surfaces.
Use the core journey with a keyboard, check labels and errors, and respect reduced-motion preferences. Save the final acceptance record with deployment notes and account ownership. Decide who will monitor inquiries and failures after release.
If a check fails, turn it into a scoped milestone using the production roadmap. If the same issue keeps returning, review keep, refactor, or rebuild.