Why Did My Vibe-Coded App Stop Working? A Checklist by Symptom

When an app built with Lovable, Bolt, Replit, v0 or Base44 stops working, the cause is usually outside the code: a paused database, used-up credits or API budget, a missing environment variable on the live site, or an auth setting still pointing at a preview URL. If it broke right after you asked the AI for a change, the last edit is the most likely cause, and rolling back is faster than asking the AI to fix it.

The rest of this guide goes symptom by symptom. Start with the first question below, because it cuts the list of suspects in half.

Write down the last time you know the app worked, and what happened since. The answer puts you in one of two groups.

• Nobody touched it and it stopped. Look at things that expire or run out: a free database that paused, a credit balance that hit zero, an API key that was revoked or hit a spend cap, or a hosting free tier that reached its limit. Go to the next two sections.
• It broke after an edit, a deploy or a settings change. Look at what changed: the AI's last edit, a new environment variable, a new domain, or a move from the builder's preview to Vercel or Netlify. Skip to the sections on preview vs live, logins, and empty data.

Before you change anything, open the browser's developer tools (right-click, Inspect, then the Console and Network tabs) and reload the page. A red error or a failed request with a status code such as 401, 404, 429 or 500 tells you far more than "it doesn't work", and it is what you should paste into the AI if you ask it for help.

This is the most common cause of an app that worked last month and now shows a blank screen, endless loading or network errors. Supabase pauses Free plan projects that have too little database activity over a 7-day period. Many Lovable and Bolt apps use Supabase, so a side project you stopped checking can go dark without any change on your part.

What to check: log in to the Supabase dashboard and look at the project. Supabase sends a warning email about a week before the pause and another once it happens, so search your inbox for both.

How to fix it: select the paused project and click Resume project. Per the same docs, the project returns with its data and settings, and you can restore a paused project for up to a year after it was paused. To stop it happening again, either keep the app in regular use or move to a paid plan, since paid projects are not paused for inactivity. While you are there, note that Free plan projects get no automatic daily backups, so export your data with the Supabase CLI if it matters to you.

Two different budgets can stop an app: the builder's credits and the AI provider's API account behind any AI feature inside your app.

Builder credits. Lovable's docs say that when a workspace has no credits left, building stops, AI features in deployed apps stop working, and apps using the built-in backend (Cloud) pause. So a Lovable app with an AI chat feature or a Lovable Cloud database can stop serving users when the balance hits zero, not only when you try to edit it. Check the credit balance in your workspace settings first.

Your own API keys. If your app calls Claude, OpenAI or another model with your key, look at that provider's billing page. On the Claude API, going over a rate limit returns an HTTP 429 error, and reaching your tier's monthly spend cap also returns 429, with access pausing until the first day of the next month unless you request a higher limit. A spend limit you set yourself returns a 400 error instead. In the Network tab these show up as failed calls to your backend or edge function, so open the function's logs to see the provider's error message.

Fix: top up or raise the limit, and add a clear error message in the app for when the AI call fails, so users see "try again later" instead of a frozen screen.

If the builder's preview works and the published or exported site does not, the difference is almost always configuration, not code. Check these in order.

• Environment variables were never added to the host. Keys you set inside the builder do not travel with exported code. On Vercel, add them under the project's Environment Variables settings, and remember that changes only apply to new deployments, so redeploy after adding or editing one. In v0, the preview only sees variables available to the Development environment, so a variable set only for Development works in the preview and is missing in Production.
• The variable is read at build time. Vite (which Lovable and Bolt projects commonly use) bakes VITE_ variables into the bundle at build time. Changing the value without rebuilding does nothing. The same docs warn that VITE_ variables are visible to anyone, so never put a secret key in one.
• Pages 404 when you refresh or open a link directly. Single-page React apps need the host to serve index.html for every route. On Netlify that is a _redirects file containing /* /index.html 200.
• The build fails with "Module not found". Vercel builds on a case-sensitive Linux filesystem, so an import of ./Header for a file named header.tsx works on a Mac and fails in the build. Match the import to the exact filename.
• Node version differs. Netlify pins a site to the Node version that was default when it was created; you can set it with a NODE_VERSION variable or an .nvmrc file. A dependency that needs a newer Node will fail until you raise it.

Login that worked in the preview and fails on your real domain is usually a redirect setting. In Supabase Auth, the Site URL is the default redirect when your code does not specify one, and it starts as http://localhost:3000. If it was never changed, confirmation emails and password resets send people to localhost. Any redirectTo URL your app uses should be on the Redirect URLs list. Fix both under Authentication, URL Configuration. For preview deployments, Supabase supports wildcards such as https://*-your-team.vercel.app/**, but the docs recommend exact URLs in production.

If logins work for you but new users never get their confirmation email, look at email sending. Supabase's built-in email service only delivers to members of your project team and allows 2 messages per hour. That is fine while you test alone and breaks the moment strangers sign up. Set up a custom SMTP provider in the Authentication settings before launch.

If you use Google or GitHub sign-in, the OAuth app in Google Cloud or GitHub also has its own list of allowed callback URLs, and it needs your new domain added.

A page that loads fine but shows empty lists, with no error on screen, often points to Row Level Security in Supabase. Once RLS is enabled on a table, no data is accessible through the API with a publishable key until you create policies. Builders and security scanners often switch RLS on, which is correct, and if no matching policy exists the result is an empty list rather than an error.

What to check: in the Supabase dashboard, open the table and look at its policies. Test the query in the SQL editor, then check whether a policy allows the logged-in user to read those rows. A common pattern is a policy that lets users read rows where a user_id column equals auth.uid().

What not to do: do not "fix" it by turning RLS off or by putting the service role or secret key in the frontend. The docs are clear that a table without RLS in an exposed schema is readable and writable by anyone with a grant on it, and a secret key bypasses RLS entirely.

If the app broke right after an AI edit, go back to the last working version first and debug second. Every major tool has a way to do it.

• Lovable: its FAQ says to revert to an earlier version when a recent change broke something, and to use Try to fix once or twice before switching to Chat or Plan mode to investigate.
• Replit: each Agent checkpoint is a snapshot you can restore with "Rollback to here". The development database is left unchanged unless you tick "Database" in the rollback options, and production databases are not restored this way.
• Claude Code: run /rewind or press Esc twice to restore code, conversation, or both to an earlier prompt. Changes made by shell commands are not tracked, so keep using git.
• Cursor, Bolt and anything synced to GitHub: commit before every risky change. If the code is in git, git log and git revert give you a reliable way back no matter which tool made the edit.

A short routine prevents most repeat failures:

• Keep a note of every service the app depends on (builder, Supabase, hosting, Stripe, AI provider) with the login and the plan you are on. When something breaks, check each one's dashboard and status page.
• Connect the project to GitHub and commit, or bookmark a version, each time it works.
• Set billing alerts and spend limits with your AI provider so you hear about a budget problem before users do.
• After every deploy, open the live site in a private window, sign up as a new user, and click through the main flow. Ten minutes catches redirect, email and environment-variable problems.
• If the app matters to you, move off free tiers that pause or sleep. The prototype-to-real-app guide covers what to change before real users arrive.