My AI App Is Not Working: How to Diagnose and Fix It

If your AI app is not working, the problem is usually in one of five places: the build, environment variables, the database, authentication, or hosting. AI tools rarely tell you which one. The fastest path is to find the real error message first, then fix that one thing. This checklist walks you through it in order.

Step 1: Find the actual error

Before changing anything:

1. Browser: open the page, press F12 (or right-click → Inspect), and check:
   • Console tab for red errors.
   • Network tab for requests with status 400, 401, 403, 404 or 500.
2. Hosting logs: in Vercel, Netlify or Replit, open the latest deployment’s build log and function/runtime logs.
3. Database logs: in Supabase or Firebase, check the logs for rejected requests.

Write down the exact error text. It’s what you (or an engineer) will search for.

Step 2: Check the build

If the deployment failed, the site won’t update. Reproduce the build locally:

npm ci
npm run build

Common messages:

• Module not found: an import points to a file that doesn’t exist, often a capitalization mismatch that works on Mac/Windows but fails on Linux servers.
• Type error: TypeScript errors that the preview ignored but the production build doesn’t.
• Command "npm run build" exited with 1: scroll up in the log; the real error is above this line.

Step 3: Check environment variables

The most common cause of “works in preview, broken in production.”

1. List every variable your app uses (look for import.meta.env or process.env in the code).
2. Make sure each one exists in your hosting platform’s settings for the production environment.
3. For Vite apps, browser-visible variables must start with VITE_.
4. Redeploy after changing variables; most hosts don’t apply them to existing builds.

Never put secret keys (Stripe secret, Supabase service_role, OpenAI) in browser-visible variables.

Step 4: Check the database

Requests return empty data or 401/403

Your database access rules may be blocking the request. In Supabase, Row Level Security (RLS) policies decide who can read or write each row. If the policy doesn’t match the logged-in user, the request is rejected or returns nothing. See Supabase’s RLS guide.

Everything works for everyone (too well)

The opposite problem: if RLS is off, anyone with your public key can read or write data. In May 2025, CVE-2025-48757 documented 170 of 1,645 Lovable-showcased apps with this issue. Check:

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

Step 5: Check authentication

• Redirect URLs: after moving to a custom domain, add it to your auth provider’s allowed redirect URLs and site URL. Otherwise login or email confirmation sends users back to the preview domain or fails.
• Email confirmation: if users never get the email, check the provider’s email limits and settings; built-in email services are often limited and meant for testing.
• Sessions: if users are logged out randomly, check cookie and domain settings.

Step 6: Check hosting and domain

• 404 on refresh in single-page apps: the host needs a rewrite rule that sends all routes to index.html.
• DNS: a new domain can take time to propagate; verify the records your host asks for.
• HTTPS: make sure the certificate was issued for both www and the root domain if you use both.

Symptom to likely cause

What you see	Most likely cause	Where to look first
Blank white page	Missing environment variable or wrong base path	Browser Console
Works in preview, broken on your domain	Different env vars or auth redirect URLs	Hosting settings, auth provider settings
Data loads for you but not for other users	RLS policy tied to a specific user or role	Database policies
Form “submits” but nothing is saved	Insert blocked by RLS, or an error the UI swallows	Network tab (look for 401/403)
Login email never arrives	Built-in email limits or missing SMTP setup	Auth provider logs
Payments succeed but orders aren’t created	Webhook not reaching your server, or wrong signing secret	Payment provider’s webhook logs
Works for a while, then slows or fails	Free-tier limits reached or a paused project	Hosting and database usage dashboards

What to send an engineer

If you decide to get help, this list saves hours of back-and-forth:

1. The exact error text and a screenshot of where it appears.
2. Steps to reproduce: which page, which button, which user.
3. When it started and what changed right before (a new prompt, a domain change, an upgrade).
4. Access to the repository and hosting, as a collaborator rather than your password.
5. Which tool built it (Lovable, Bolt, Replit, Cursor, v0) and whether you’ve edited code outside it.

Never send secret keys in chat or email; share them through a password manager or let the engineer request their own access.

When to stop prompting the AI

Stop and get a human to look when:

• Two or three focused attempts didn’t fix it.
• The AI “fixes” one thing and breaks another.
• The problem involves payments, user data or access control.
• You don’t know whether a fix actually worked.

Broad prompts like “fix everything” often rewrite working files and make it harder to recover. Commit working states to Git so you can roll back.

Common mistakes

• Changing several things at once, so you don’t know what fixed (or broke) it.
• Disabling security rules to make an error go away.
• Pasting secret keys into the AI chat or frontend code.
• No Git history, so there’s no way back to the last working version.

More in how to fix AI-generated code and vibe coding cleanup services.

When to get help

If your app has users waiting, takes payments or stores personal data, it’s worth having an engineer look rather than guessing. Black Engine Technologies is a software engineering studio in Monterrey, Mexico (UTC-6) with 12+ years shipping production software, and we work daily with AI coding agents. Send us a WhatsApp message with the error you’re seeing and we’ll take a look.