Why Is My AI-Built App Not Working? Error Codes Explained

Start with the symptom, not a guess

Work through it in this order: get the exact error, match your symptom in the table below, read what the error code means, and only then give your AI the details. Each row links to the section or guide that explains the fix.

Get the real error before you re-prompt

Open the live site, not the builder's preview, and open your browser's developer tools (press F12, or right-click the page and choose Inspect). Then repeat the exact action that fails. The Console tab shows error messages. The Network tab lists every request the page made; a failed one shows in red with a number in its Status column. That number is the status code the next section explains.

If the failing part runs on the server (a form that saves, a payment, an email), your builder or database usually also keeps logs of each server function. The message there is often more specific than anything the browser shows. Our guide to describing a bug to your AI covers where to find the error text and how to pass it on.

What the error codes mean, in plain English

Every time your app asks a server for something, the server answers with a three-digit status code. The web standard that defines them (RFC 9110) groups them by the first digit, and that first digit is the most useful thing to know. A code starting with 4 means the request itself was the problem: the standard says the client "seems to have erred". A code starting with 5 means the server failed or couldn't do it. So a 4xx usually points at something your app sent or wasn't allowed to do, and a 5xx points at the server side.

Two more things worth knowing. First, 401 and 403 look alike but point different ways: a 401 is about who you are (sign-in), a 403 is about what you're allowed (permissions). Second, some platforms use their own numbers outside this list. When you see one, the platform's own documentation is the only reliable place to look it up; don't let your AI guess what it means.

Why does my app show nothing, with no error at all?

Often because a permission rule is working, not because anything is broken. Many databases behind AI-built apps use row-level security: rules that decide which rows each signed-in user may see. When a rule doesn't let the current user see a row, the database doesn't raise an error. It returns an empty list, as if the rows don't exist.

Supabase, a database many AI website builders connect to, puts it plainly in its troubleshooting documentation: when a query comes back empty, "usually this means you have RLS (row level security) enabled and no policy, or do not meet the policy." Saving is different. A new row the rules don't allow is refused with an error, but an edit or delete the rules don't allow can quietly change nothing, so check the row afterwards.

The usual causes, all fixable without touching the connection:

• No rules yet. Row-level security is on for the table, but nobody wrote a rule that allows reading, so everything is hidden.
• The rule checks the wrong thing. For example, it compares the user's ID with a column called user_id when the table stores the owner in owner_id.
• The app asks too early. The page loads the data before sign-in has finished, so the request arrives as a stranger and the rule rightly hides everything.

Rewriting the connection settings won't fix any of these. Ask your AI to show you the rules on the table in question and explain, in plain English, who each rule lets see what.

When an outside service gets the error

A payment gateway confirming a payment, or a messaging service passing on a message, calls your app's backend (the part that runs on a server, not in the visitor's browser) directly. It can't sign in as one of your users, so if that function only accepts requests from signed-in users, the call is refused with a 401 or 403 before your code even runs. The fix is to let that one function accept calls without your app's sign-in and have it check the sender another way, usually a signature the service adds to every call. Our guide to what a webhook is explains the idea, and webhook signature verification failed covers the signature check.

A related trap: typing a server function's address into your browser's address bar is not a fair test. Your browser sends a plain request with no sign-in and none of the data your app would send, so it can show an error even when the function works. Test it the way your app calls it, or with the test tool your builder or database provides.

When it worked yesterday and nothing changed

If no one touched the code, look outside it first:

• A paused database. Some providers pause free projects that see little use, and requests fail until you restore the project. Your provider's current plan terms say when that happens.
• An expired or changed key. A key for an outside service was replaced (rotated) or expired, and the next call fails with a 401 or 403.
• A rate limit. A burst of activity hit the provider's limit and you're getting 429s.
• An outage. The provider is having a bad day. Check its status page before you change anything.

Why the AI didn't catch these failures

An AI coding agent writes code from what the conversation showed it: your prompts, the data you tested with, the path you clicked through while the app looked finished. It can't allow for a live site it never saw, an input it was never shown, or two users acting at once when only one person ever tested it. That's the limit of building from one demonstrated run, not a defect in the tool. Our guide to why a vibe-coded app isn't production-ready yet goes deeper into why it happens.

Does my AI builder have a real database behind it?

Usually, yes. Many AI website builders, Lovable and Base44 among them, now come with a database, sign-in and server functions built in. If your data still disappears on refresh, the gap is that a table, a permission rule or the link between the screen and the database was never set up for that feature.

So ask your AI where that particular data is saved, and to show you the table. If the answer is "in the browser" or "in the app's memory", that's the cause.

Preview and live are two different places

The builder's preview runs somewhere the builder fully controls. Your live site, whether on the builder's own hosting or on another host, is a separate environment. It needs its own copy of every environment variable (a setting, such as a key or an address, that the app reads when it runs), build setting and redirect rule the preview relied on, and nothing carries across on its own. When a site works in preview but shows a blank screen or a failed request once it's live, compare those settings first, before you look for a new bug. Our guide to environment variables not working after deploy explains the mechanism.

The prompt to give your AI

Once you have the exact error, paste this into your AI website builder's chat or give it to your AI coding agent. Fill in the three lines at the top. It asks the AI to explain the cause before it changes anything, so a guess doesn't break working code elsewhere.

I'm not a coder. Something in this project isn't working.

What I did: [the exact steps, e.g. "signed in, opened Orders"]
What happened: [e.g. "the list is empty" or "a red error"]
The exact error: [paste the console message, the status code
from the Network tab, or the server log line]

Don't change any code yet. First, in plain English:

1. Explain what this error or status code means.
2. Tell me where it happens: in the browser, in a server
   function, in the database, or at an outside service.
3. Give the most likely cause in this project, and how you
   know. If it could be a permission rule (row-level security)
   hiding data, check that and show me the rule.
4. Tell me whether it depends on a setting that exists in
   preview but might be missing on the live site.
5. Describe the smallest change that would fix it, and what
   else that change could affect.

If you're not sure, say so and tell me what to check next,
instead of guessing.

What to check in the AI's answer

• It explained the error before offering a fix. If it jumped straight to rewriting code, ask it to go back to steps 1 to 3.
• The cause matches the code. A 401 answer should be about sign-in or a key; a 403 answer about permissions; a 5xx answer should point at the server log, not the page layout.
• It named a place. "Something in the backend" isn't enough. Ask which function, table or setting.
• For an empty list, it looked at the permission rules before blaming the connection.
• The fix is small. A fix that rewrites several files for one error is often a guess. Ask why each change is needed.
• It didn't move a secret key into the page. A key for a paid or private service belongs in a server function, never in code that runs in the browser. Our guide to why an API key can't go in frontend code explains why.
• It didn't ask you to switch security off. Turning off row-level security or removing a sign-in check to "make it work" swaps an error for an open door. Ask for the rule that allows only what you need.