My Lovable or Bolt app stopped working: how to find what broke

It worked yesterday. Today the save button does nothing, the list comes back empty, or the screen is just white. If you built the app with Lovable, Bolt, v0, Replit or Cursor, your first instinct is probably to type "fix it" into the chat. Sometimes that works. Other times you end up in a loop where every attempt changes something else and the original problem is still there.

This guide is about getting out of that loop. You don't need to be a developer. You need a repeatable way to read what your app is already telling you.

1. Reproduce the bug before you change anything

Before asking for any change, make sure you can trigger the problem on purpose. Write down:

1. What you do: "I log in, open Customers and click Save."
2. What you expect: "The customer shows up in the list."
3. What actually happens: "The button spins for a second and nothing happens."
4. Where it happens: in the preview, the published version, or both? On mobile and desktop?

Also try a private/incognito window. If it works there, the cause may be a stale session or data cached in your browser rather than the code.

Those four lines are the most useful thing you will produce today. They help the AI, they help you, and they help anyone you ask for help later.

2. Open the browser console

Your browser logs errors even when the page shows nothing. To see them:

• In Chrome or Edge, right-click the page → Inspect, or press F12 (Cmd + Option + I on a Mac).
• Open the Console tab.
• Reload the page and repeat the step that fails.

Look for red lines. A few common messages and what they usually mean:

• Cannot read properties of undefined: the code is trying to use data that never arrived. The real cause is often the database query, not the screen.
• is not defined or is not a function: something was renamed or deleted in the last change.
• Failed to fetch or a CORS error: the app can't reach its server or an external API.

You don't need to understand the whole message. Copy the full text of the first red error, not the last one. The first is usually the cause; the rest are side effects.

3. Check the Network tab

In the same developer tools panel, open Network and filter by Fetch/XHR. Repeat the failing action and watch the requests that show up. Look at the Status column:

• 200: the request succeeded. If you still see no data, open the Response tab; it may simply be empty.
• 400: the app sent something malformed, such as a field that doesn't exist in the table.
• 401 / 403: a permissions or session problem. With Supabase this almost always points to authentication or to the table's Row Level Security rules.
• 404: that address doesn't exist; a function or table may have been renamed.
• 500: something failed on the server. Time to read the logs (step 6).

One thing that trips up a lot of people: in Supabase, if a table has Row Level Security enabled and no policy lets you read it, the query doesn't fail. It returns an empty list. If your page is empty and the request says 200, check that table's policies.

4. Look at what the last prompt changed

Bugs rarely appear out of nowhere. Ask yourself what the last change was before things broke, and look at which files the AI touched. Lovable, Bolt and most similar tools show the changes made by each message, and if your project is connected to GitHub you can open every commit and see the exact diff.

Red flags in a change:

• It edited files unrelated to what you asked for.
• It renamed tables, columns or variables.
• It added or modified a database migration.
• It deleted code that was "unused".

5. Roll back to the last version that worked

Almost every vibe-coding tool keeps a version history. Look for History, Restore or Revert. Rolling back gets you to a stable point from which you can request the change again, more carefully this time.

There is one catch: restoring the code doesn't always undo database changes. If the last prompt created or altered tables in Supabase, those changes may still be there after the code goes back. If something still fails after a restore, check the table structure.

6. Read your Supabase logs

If your app uses Supabase, the dashboard has a Logs section with separate logs for the API, the database (Postgres), Auth and Edge Functions. Filter to the time when you reproduced the bug and look for:

• Messages like new row violates row-level security policy, which means a policy is blocking an insert.
• Errors about columns or tables that don't exist.
• Failing Edge Functions, along with the exact error message.

If you use Firebase or another backend, the idea is the same: find the server error log at the exact moment of the failure.

7. Write a better prompt (or stop prompting)

With everything above, you can write a far more useful prompt than "it's broken, fix it":

When I click Save on the Customers page, the POST request to the clients table returns 403 and the logs say "new row violates row-level security policy". This started after I asked for the "company" field. Don't change anything else; first explain which policy is failing and why.

Asking the AI to explain before it changes anything cuts down on blind fixes.

When to stop asking the AI

Set a limit. If the problem is still there after two or three well-described attempts, or you notice any of these, stop:

• Every fix breaks something different.
• The AI suggests a solution you already tried.
• It starts rewriting large parts of the app for a small problem.
• The bug involves payments, user data or permissions.

At that point, pushing on usually makes the code worse. Go back to the last stable version and ask for help with the information you have already gathered.

Quick recap

• I can reproduce the bug and described it in four lines.
• I copied the first red error from the console.
• I checked the status code in the Network tab.
• I know what the last prompt changed.
• I know which version was the last one that worked.
• I checked the backend logs at the time of the failure.

Still stuck?

At this point a second pair of eyes usually saves days. At Devonauts we help people who built their app with AI figure out what broke, fix it, and understand why it happened, with no judgement about the code. You can run the free health check, see how our AI app rescue works or tell us what's going wrong. And if your app is close to launch, our security checklist for AI-built apps is a good next read.