An AI-built app can work in preview and fail in production because the deployment changes its hostname, configuration, runtime, and integration endpoints. The preview may also reuse an authenticated session or test data that a real customer will not have. Diagnose the first failing step on the published URL rather than assuming the entire application needs a rewrite.
Key takeaways
- A preview tests one environment; production introduces another.
- Redirect URLs and external callbacks must point to the production host.
- Development data and sessions can conceal missing setup.
- Verify the full journey with a fresh account and a direct page load.
The hostname changes more than the address bar
Authentication emails, checkout returns, webhook endpoints, and application links can contain absolute URLs. If any still point at a preview host, users may arrive in the wrong environment or events may reach an old deployment. Search configuration and application code for preview URLs, then review each use instead of replacing strings blindly.
With Supabase Auth, set the site URL and redirect allowlist for the intended domains. Test login, email confirmation, and password recovery separately: each can use a different callback path. Do not use a broad production redirect pattern merely to silence an error.
Configuration is scoped to the deployment
A local environment file does not automatically populate a host’s production settings. List each variable the application expects, identify whether it belongs in the browser or server, and compare names with the deployment configuration. Change a value and rebuild when the framework embeds that value into the browser bundle.
Public configuration can identify a service. A private credential grants authority and must stay on the server. If you find a private key in a shipped bundle, remove it and rotate the exposed credential; hiding the UI is not a remedy.
Preview sessions can hide authentication failures
A builder preview may run while you are already signed in. That bypasses signup, email delivery, redirect validation, and session creation. Use an incognito session with a new ordinary account. Complete registration, confirm the email, refresh a protected route, sign out, and attempt to revisit it.
Repeat the core data action with a second account. Being able to log in is separate from being authorized to access a record. Review RLS and server-side permission checks for the specific records your product stores.
Payments need independent verification
A checkout page opening successfully is only one step. Check the Stripe mode, price IDs, return URLs, and event destination. Confirm a webhook is delivered and its signature is checked using the untouched request body. Handle duplicate events without granting duplicate entitlements.
Stripe documents automatic retries for failed webhook deliveries and does not guarantee event ordering. A handler that assumes a single delivery or a fixed order can pass a quick demo and fail later. Use the integration’s payment state as the authority for access.
Reproduce a production failure deliberately
Write down the production URL, device, account state, and exact steps. Check the browser network panel and hosting logs at the same time, removing private data from anything you share. Work backward from the first failed request: which service rejected it, what configuration did it use, and what response did the UI display?
After the fix, retest the original failure and the adjacent journey. A redirect repair is not complete until a user can finish confirmation and reach the expected screen. Keep the preview environment useful, but use separate configuration so testing cannot silently alter production data.
Continue with the production roadmap or the launch checklist.