My Lovable app works for me but breaks for a user. Where do I start?

Get the user's exact words and the screen they were on, then reproduce in a private window on their device type. Most "works for me" bugs are a logged-out state, a stale cached build, or an environment variable that only exists locally.

How do I see errors in production when I did not write the code?

Open the browser console on the failing page and read the first red line, not the last. Then find the file it names in your repo and ask your AI editor what that function assumes. If you want reports to arrive with the console and screenshot attached, install a bug-report SDK.

Is it safe to paste the error into Cursor or Claude Code?

Yes, as long as you strip user emails, tokens and API keys first. Give the agent the error, the file it names and one sentence of what the user was trying to do; ask for the smallest change that fixes it and a test.

How do I stop the same bug from coming back?

Write the cause down where the agent will read it next time: a comment at the site, a rule file, or a lessons file your editor loads. Then add the failing case to a test before you ask the agent for the fix.

Your Lovable app broke in production. Now what?

You shipped an app with Lovable, Bolt, Cursor or Claude Code. It works for you. A user messages “it’s broken”. You open the code and it is a few thousand lines you have read once, if that.

This is a checklist for that afternoon. It assumes you can open the browser console and you have an AI editor. Most of it has nothing to do with Mushi; one step does.

1. Get the user’s exact words and their screen

“It’s broken” is not a bug report. Ask for three things: what they were trying to do, what happened instead, and the page they were on. If they can send a screenshot, take it. Ask what device and browser; “iPhone, Safari” or “work laptop, Edge” narrows the search more than any log.

2. Reproduce in a private window, logged out

Open a private window on the same page. Most “works for me” bugs are one of three things: you are logged in and they are not, you have a fresh build and they have a cached one, or you have an environment variable locally that the deployed app does not. Check those three before reading any code.

3. Read the first red line in the console, not the last

Open the browser console on the failing page and scroll to the first error. Later errors are usually consequences of the first. Copy the message and the file:line it names. If the console is clean, open the Network tab, repeat the action, and look for a request that returned 4xx or 5xx; the response body usually says why.

4. Find the file and ask what it assumes

Search your repo for the file or function the error named. Do not try to understand the whole module. Ask your editor’s agent: “What does this function assume about its inputs, and which of those could be false for a logged-out user on Safari?” Generated code tends to assume the happy path it was generated against.

5. Ask for the smallest fix, and a test

Give the agent the error, the file, and one sentence of what the user was trying to do. Ask for the smallest change that fixes it and a test that fails without the change. Refuse the refactor it offers on the side. Strip user emails, tokens and keys from anything you paste.

6. Ship, then tell the user

Deploy, reproduce once more in the private window, and reply to the user with what you changed. People who hear back report the next bug too.

7. Write the cause down where the agent will read it

Add a one-line comment at the site, a rule to your editor’s rules file, or an entry in a lessons file the agent loads. The bug you fix today is the bug the agent reintroduces next month unless the reason is in its context.

8. Make the next report arrive with all of this attached

Steps 1 to 3 are the expensive part, and a user cannot do them for you. An in-app bug reporter can: Mushi Mushi is an open-source SDK that lets the user report from a widget or a phone shake, attaches the screenshot and the console/network tail, writes a plain-English diagnosis of what broke and why, and hands the fix prompt to Cursor or Claude Code over MCP. One command installs it:


npx mushi-mushi

Free Cloud is 50 diagnoses a month with no card; self-hosting is free. Other tools that solve parts of this are compared on Sentry alternatives for solo founders.

Start free — 50 diagnoses/mo, no card

Frequently asked questions

My Lovable app works for me but breaks for a user. Where do I start?: Get the user's exact words and the screen they were on, then reproduce in a private window on their device type. Most "works for me" bugs are a logged-out state, a stale cached build, or an environment variable that only exists locally.
How do I see errors in production when I did not write the code?: Open the browser console on the failing page and read the first red line, not the last. Then find the file it names in your repo and ask your AI editor what that function assumes. If you want reports to arrive with the console and screenshot attached, install a bug-report SDK.
Is it safe to paste the error into Cursor or Claude Code?: Yes, as long as you strip user emails, tokens and API keys first. Give the agent the error, the file it names and one sentence of what the user was trying to do; ask for the smallest change that fixes it and a test.
How do I stop the same bug from coming back?: Write the cause down where the agent will read it next time: a comment at the site, a rule file, or a lessons file your editor loads. Then add the failing case to a test before you ask the agent for the fix.

Facts checked 2026-09-21 against the linked sources. Next review due 2026-12-21. Rows marked “unverified — check before publishing” could not be confirmed on that date.