What to Do When Your Lovable, Bolt, or Rork App Breaks in Production

Something's broken. Users are telling you things aren't working. Or you went to test something yourself and it stopped functioning. Or someone important is trying to use your app and it's showing a blank screen.

If you built with Lovable, Bolt, or Rork, this moment feels particularly bad — because you don't have the code fluency to diagnose what's happening, and the AI that built the app doesn't have the context of your production environment.

This guide is the triage playbook for this situation. It's designed for non-technical founders who need to either fix something themselves, explain the problem clearly to a developer, or decide whether this is a "I can handle this" problem or a "I need help" problem.

First: Distinguish the Type of Failure

Not all production bugs are the same. The type of failure determines how urgent it is and what you do next.

Category 1: Critical — Fix Within Hours

• Users can't sign in or sign up (auth system broken)
• Payments are failing or not processing (revenue-blocking)
• Data is missing or corrupted (user data affected)
• Security vulnerability actively being exploited

Category 2: High — Fix Within 24–48 Hours

• Core user journey is broken (users can't do the main thing)
• Emails aren't sending (new users stuck in signup)
• Mobile layout is completely broken for a significant portion of users

Category 3: Medium — Fix in Your Next Development Sprint

• Secondary features not working
• Performance is slow but functional
• Edge cases in non-critical flows

Category 4: Low — Fix When You Get to It

• Visual inconsistencies
• Copy errors
• Non-blocking UX issues

Before doing anything else, categorize what you're dealing with. Category 1 is drop-everything. Category 4 can wait until you have development time.

Step 1: Reproduce the Problem Exactly

The most valuable thing you can do before calling anyone or touching any code is to reproduce the problem consistently and document exactly what you did to trigger it.

Write down:

• What were you doing when it broke?
• What exactly did you see? (Screenshot or screen recording is best)
• What did you expect to happen instead?
• Can you reproduce it? Every time, or intermittently?
• Does it happen on all devices/browsers, or specific ones?
• Does it happen for all users, or specific users?
• When did it start? Was there a recent change?

This documentation transforms a vague "it's broken" into a specific problem statement that a developer can act on. The difference between "the payment page doesn't work" and "when a user on Safari mobile clicks the payment button, the loading spinner appears and nothing happens for 30 seconds, then the page reloads to the home screen without any error message" is the difference between hours of debugging and hours of guessing.

Step 2: Check the Browser Console

This step gives you information even if you don't know what it means — and what you find here is what a developer will ask you for immediately.

How to open it: In Chrome or Firefox, press F12 (Windows) or Command+Option+J (Mac). You'll see a panel with several tabs. Click "Console."

What you're looking for: Red text. Red lines in the console are errors. Screenshot everything in red.

What you're also looking for: The Network tab (also in the developer tools panel). Click it, reload the page, and reproduce the problem. Look for rows highlighted in red — these are failed network requests. Note the URLs and status codes (404, 401, 500, etc.).

You don't need to understand what these errors mean. You need to capture them so a developer can.

Step 3: Check Supabase (If Your App Uses It)

Most Lovable and Bolt apps use Supabase as the database and backend. Supabase has its own logging that's separate from your app.

Log into your Supabase project → navigate to Logs → API Logs.

Look for requests with error status codes (400, 401, 403, 500). The error message attached to these requests often tells you exactly what went wrong — a missing RLS policy, a constraint violation, a malformed query.

Also check: Authentication → Users. Can you see your user accounts? If the user table is unexpectedly empty or incomplete, the auth system has a problem.

Step 4: Identify Whether It's a Code Problem or a Configuration Problem

Production bugs in AI-generated apps fall into two broad categories, and the fix is different for each.

Code problems: Something in the application logic is wrong. A function is missing, a component has an error, a query is malformed. These require code changes.

Configuration problems: The code is fine but something in the environment is broken. An API key expired. A Stripe webhook stopped receiving events. A domain DNS record is wrong. An environment variable got changed or deleted.

Configuration problems are often faster to fix than code problems, even for non-technical founders. Common checks:

• Check your environment variables. In your Vercel or deployment settings, verify that all required API keys and secrets are present and haven't been rotated without updating the deployment.
• Check your Stripe webhook status. In the Stripe dashboard, go to Developers → Webhooks. Is your endpoint receiving events? Is the secret correct?
• Check your deployment status. In Vercel or whichever platform you're deployed on, is the latest deployment successful? A failed deployment can leave users on an outdated version.

Step 5: Try to Reproduce in Development

If you have a development version of your app (a separate environment, not the live production one), try to reproduce the problem there. If it reproduces in development, you can fix it safely without affecting live users. If it doesn't reproduce, the bug is environment-specific — something in production configuration vs. development configuration is different.

The most common reason a bug appears in production but not in development: environment variables, database content differences, or recently changed Stripe/API configurations.

When to Get a Developer Involved Immediately

Stop trying to self-diagnose and get a developer on this immediately if:

• User data may be affected. If there's any possibility that data was corrupted, deleted, or exposed to the wrong users, this is a drop-everything situation. The longer you wait, the worse it gets.
• You're losing Category 1 revenue. Payment failures that you can't trace to a specific configuration issue need developer attention fast.
• You've been trying to fix it for more than 2 hours without progress. The opportunity cost of a non-technical founder debugging a production issue for a full day is high. Spending that time on things you're actually good at and getting a developer to fix a 1-hour issue is almost always the right call.
• Something changed and you don't know what. If the app was working yesterday and broke today and you haven't touched it, something outside your direct control changed — an API provider updated their schema, an SSL certificate expired, a Supabase dependency changed. These are developer problems.

How to Explain the Problem to a Developer Clearly

When you contact a developer for help, give them:

1. A description of what's broken — specific, reproducing steps
2. A screenshot or recording of the failure
3. Console errors (from browser developer tools)
4. The time it started — as precisely as you know
5. Whether anything changed recently — a new deployment, a config change, anything at all
6. Your urgency level — Category 1 (fix today) vs. Category 3 (fix this week)

A developer who receives this information can usually diagnose the issue within 30 minutes. A developer who receives "the app is broken, please help" starts from zero.

Preventing the Next Emergency

Most production emergencies in AI-generated apps are preventable. The patterns that prevent them:

Error monitoring from day one. Sentry or equivalent. You find bugs before users have to report them.

Staging environment. A second deployment of your app where you test changes before pushing to production. Takes an afternoon to set up, saves hours of emergencies later.

Database backups verified. Know where your Supabase backups are and confirm they're running. Test restoring from a backup before you ever need to.

Webhook monitoring. In Stripe and any other webhook-based integrations, check the webhook delivery status weekly. Failing webhooks are silent — they don't break the UI, they just stop updating your database.

Environment variable documentation. Keep a list of every environment variable your app requires and what each one does. When something breaks after a deployment, this list is where you look first.

---

If your app has a production issue you can't resolve, or if you're tired of firefighting bugs in a codebase that wasn't built for production, book a free call. We'll diagnose what's happening and tell you the fastest path to a stable, production-ready app. Book a free call →