Fix a broken AI-built app

The HTML being served asks for JavaScript files that are not there. That happens when the page was cached from an older deploy, or when the build output went somewhere the server is not looking. The browser gets a blank page because the code that draws it never arrives.

What to do: Redeploy, then load the page in a private window. If the private window works and your normal browser does not, it is a cache and it will clear on its own — force-reload to confirm.

The published JavaScript still contains the placeholder for a value that should have been filled in when the app was built. These are baked in at build time, so setting them after the fact changes nothing until you rebuild — which is exactly why an app can be perfect in preview and dead once published.

What to do: Set the variable in your host's environment settings for the production deployment, then trigger a fresh build. Re-publishing without rebuilding will not pick it up.

The app failed on its way up, so nothing was ever drawn. On an AI-built app this is most often a client being constructed with a configuration value that is missing — the code assumes it is there, it is not, and the failure happens before a single element renders.

What to do: The error message names what broke. If it mentions an undefined value or a malformed URL, you are looking at a missing environment variable in the published build rather than a bug in the code.

Row-level security decides which rows each visitor may read. When a policy is missing or does not match how your app signs people in, the database does not raise an error — it returns an empty result. So the page renders perfectly with nothing in it, and there is no error anywhere to search for.

What to do: Check that row-level security is enabled on the table AND that a policy exists which matches the signed-in user. An enabled policy with no matching rule blocks everything.

Requests to your database are coming back rejected. The key the published app is using is either missing, wrong, or was replaced without the app being rebuilt. Nothing loads because every query is refused before it runs.

What to do: Check the database key in your production environment against the one in your project dashboard, then rebuild. A key changed in one place and not the other produces exactly this.

The database answered that the table does not exist. Almost always this means the deployed app is pointed at a different database project than the one you built against, or the migrations that create the table were never applied to it.

What to do: Compare the database URL in your production environment with the one you developed against. If they match, the migrations have not run against it.

The page itself failed on the server, so nothing was ever sent to the browser. On an AI-built app this is most often a missing environment variable or a crash in code that runs before the page renders — neither of which is visible from outside.

What to do: Open your host's runtime logs for this deployment. The first error in them is the cause; everything after it is usually noise.

Your app crashed while rendering and the framework replaced it with a default error screen. The message it shows publicly is deliberately vague; the real error is in your server logs.

What to do: Open the runtime logs for this deployment and read the first error.

The page is requesting one of its own API routes and getting “not found”. The route exists in your project but was not included in what got published — usually because the deployment is configured for a static site, or the build put the functions somewhere the host is not looking.

What to do: Check whether your host shows any functions for this deployment. If the list is empty and your app has API routes, the build output is being treated as a plain static site.

The page called its own backend and the backend failed. Whatever it needed — a secret, a database connection, a third-party service — is not there or is not answering. The browser gets an error with no detail in it by design.

What to do: Open your host's function logs and read the first error from that route. It will name the missing piece directly.

The page is served over HTTPS but asks for files over plain HTTP. Browsers block these silently, so whatever they were for simply does not work, with nothing visible to explain it.

What to do: Change those URLs to https, or host the files yourself.

This app installs a service worker, which caches the site in each visitor's browser. When one gets stuck it keeps serving an old build to people who have visited before, while a new visitor sees the current one.

What to do: Open the site in a private window. If it works there and not in your normal browser, this is the cause — clear site data for the domain.