When a Lovable app works perfectly in preview and then fails on the live site, the cause is almost always a difference between the two environments rather than a mystery bug. Auth redirect settings, environment variables, custom domain configuration and database permissions are the usual suspects. This post walks through how to find which one is biting you, how to fix it properly and when it is time to get a second pair of eyes on the app.
We work with Replit, Lovable, Bolt, Cursor, v0, Base44 and Claude Code.
Our Vibe Code Cleanup and Production Readiness service starts with a fixed-price App Launch Audit. Or start with a free health check.
Preview and production are two separate operating conditions, even when they display the same screen. They can use different web addresses, environment variables, authentication settings, database permissions and build processes. A preview may run inside a builder with settings already supplied, while the published app needs its own production configuration. This can make a feature appear finished even though the live version has never completed the full journey. Start by reproducing the problem on the published domain and writing down the exact action that fails. Is the screen blank, does login loop, or does a particular record fail to load? A clear symptom narrows the search. Treat preview as a useful test environment, not proof that production has been configured.
Authentication providers only send a user back to addresses that are permitted in their configuration. If the live domain is missing from the site URL or approved redirect list, a successful login can send someone back to the preview URL, show an error or repeat the sign-in screen. Check the provider's configured site address and every redirect used by sign-in, email confirmation and password recovery. Include the exact live domain and any legitimate production path the app needs. Avoid adding broad wildcard addresses simply to make the error disappear. After changing the settings, publish again and test in a private browser window so an old session does not hide the result. Confirm the whole journey from sign-in through returning to the intended page.
Preview may already have the keys and URLs your app needs, while the production deployment has a separate set of variables. Compare the names and intended values without copying secret values into chat, screenshots or browser code. A missing public URL can break a request, and a missing server-side credential can prevent the app from reaching a provider. Never place secret keys in front-end variables: anything bundled into browser code can be inspected by visitors. Keep private credentials in the deployment's secret store and only use them from server code. Check that production points to production services and not a development database. Make one configuration change at a time, redeploy and verify the result against the original symptom.
A live app showing no records does not necessarily mean the database is down. A policy may be doing exactly what it was written to do, while the application's signed-in user or ownership data does not match the policy's assumptions. The opposite is more serious: if records appear to everyone, policies may be too permissive or absent. Review the access rules for each table and test with a logged-out visitor, the record owner and a second ordinary user. Do not use a privileged service key in the browser as a shortcut. A useful plain-English checklist is in Is Your Vibe-Coded App Secure?. Data access should be verified at the database boundary, not inferred from which buttons the interface displays.
A domain change touches several layers. Confirm the DNS records point where the hosting platform expects, the certificate is valid, and the app's canonical live address is the one registered with authentication. Mixed content, where a secure page requests an insecure resource, can also block scripts or requests. If a page still looks like an older release, clear cached files or try a private window before changing code. Give DNS changes time to propagate, but verify the records rather than guessing. Test both the root domain and any www version you intend to support, then redirect one consistently to the other. A correct domain setup gives auth, links and analytics one stable production origin.
Change one variable at a time and preserve a working checkpoint before touching code or settings. Open the browser console and network panel, then capture the first meaningful error and the request that failed. Share that exact evidence with the AI tool instead of describing only that the app is broken. Ask it to explain the likely cause and name the files or settings it intends to change before it edits anything. After a change, test the same failing path and one adjacent journey that could be affected. If each prompt creates a new symptom, pause and inspect the changes rather than piling on another broad instruction. This guide to the AI regression loop covers a disciplined way to get unstuck.
If you have spent more than a day repeating the same fixes, or the problem touches authentication, payments or personal data, a second pair of eyes can be cheaper than another round of guesswork. A live launch is the wrong moment to discover that the preview used different permissions or credentials. Start with a free health check by sharing the app link and the thing that worries you. If the app needs a fuller review, the App Launch Audit gives you a prioritised report, launch readiness score and rescue-or-rebuild verdict. You keep the choice of what happens next. The aim is not to replace your builder, but to understand the fault and make a safe, deliberate change.
A blank page after publishing usually means the app hit an error while loading. Common causes are a missing environment variable, an auth redirect that points back to the preview address, or a failed request to the database. Open the browser console on the live site, note the first red error and fix that cause first.
Your auth provider only redirects users to addresses you have approved. If the live domain is not listed in the site URL and redirect URL settings, users get sent back to preview, see an error or loop on the login page. Add the live domain, publish again, and test in a private browser window.
Prompting works when you can describe the exact error. If you have tried several prompts and each one changes something else, stop and diagnose first: the console error, the failing network request and the setting involved. If the issue touches auth, payments or personal data, an independent check before launch is worth the time.
TPR Media helps Australian founders review, stabilise and launch apps built with AI coding tools, starting with a fixed-price App Launch Audit.
Still stuck between preview and live? Send us your app link and the error you are seeing. We will reply with the first three things we would investigate. Get a free health check