Every build breaks eventually. The difference between people who ship and people who give up is not luck, it is having an order to work through when the preview goes white. This is that order, based on the errors that come up most often in Lovable projects.
Short answer: read the actual error text, paste it into the chat verbatim, and change one thing at a time. The costly pattern is retrying the same vague prompt and hoping. Three identical retries cost credits and usually make the code messier.
First, tell the four failure types apart
They look similar and they need different fixes.
- Build error. The app fails to compile. Usually a missing import, a typo, or a file the agent referenced but never created. The error message names a file and a line.
- Runtime error. The build succeeds but the page crashes when it loads. Often reading a property of something undefined, or data that arrived in a different shape than the component expected.
- Blank white screen. No visible error at all. Usually a crash during the first render, a failed data fetch on the server, or a route that renders nothing.
- Wrong behaviour. Everything runs, the app just does not do what you asked. This is a prompt problem, not a code problem.
The order to work through
1. Read the error, do not summarise it
Open the console or the error panel and copy the whole message including the file name and the stack. Paste it into the chat with one sentence of context: "This appears when I open the booking page after login." A specific error plus the moment it happens gets fixed on the first attempt far more often than "the page is broken".
2. Reproduce it in a fresh session
Open the preview in a private window. If the error disappears, you are looking at cached state or a stale login session, not a code bug. Clearing site data fixes a surprising share of "it broke for me but not for you" reports.
3. Undo before you patch
If the app worked ten minutes ago, the fastest fix is reverting to the last version that worked, then re-describing the change more precisely. Patching forward on top of a broken state usually creates two problems. Version history exists for exactly this, and reverting costs nothing.
4. Fix one thing at a time
When you ask for three fixes in one prompt and the result is still broken, you cannot tell which fix failed. One change, verify, next change. It feels slower and it is faster.
Specific errors and what they usually mean
Cannot read properties of undefined
The component tried to use data that has not arrived yet, or a field that does not exist on the object. Two fixes, and you usually want both. Handle the loading state so the component renders something while data is in flight, and use optional access so a missing field does not crash the page. Prompt: "The profile card crashes with cannot read properties of undefined when data is still loading. Add a loading state and guard against missing fields."
Module not found or failed to resolve import
The agent referenced a file or a package that does not exist in the project. Either the file needs to be created or the package needs to be installed. Prompt: "The build fails with module not found for this import. Create the missing file or install the package, then verify the build."
Hydration mismatch
The server rendered one thing and the browser rendered another. Common causes are reading browser storage during the first render, using the current date and time directly in a component, or generating a random value while rendering. Fix by moving that logic into an effect that runs after the page loads.
Blank white page after a refresh
Refreshing a deep page such as a blog post exercises the server rendering path, while clicking a link from the home page does not. If it only breaks on refresh, the problem is in what the server does before the page renders, usually data returned in a shape the server cannot serialise. Say exactly that: "The page renders when I navigate to it, but refreshing shows a blank screen. Check the server side loader for this route."
Data does not save, or the list is always empty
Check the browser network tab for the failing request first. A permission error means a database policy or grant is missing rather than a broken component. That path is covered in the database guide, and fixing it in the front end is wasted effort.
Styles look wrong only on mobile
Fixed widths, absolute positioning and long unbroken text are the usual causes. Ask for a responsive audit of the specific section rather than the whole app: "Make the pricing section work from 320px upward without horizontal scrolling."
How to escape a fix loop
If two attempts have not worked, stop repeating the prompt. Change the approach instead.
- Switch to Plan mode and ask for a diagnosis rather than a fix. "Do not change anything. Explain what is causing this error and list two ways to fix it."
- Ask for the simplest possible version. Replace the broken component with a plain one that renders static content, confirm the page loads, then add complexity back.
- Revert to the last working version and re-describe the feature with more detail than last time.
- Take the code to another model for a second opinion. Pasting a file into Claude and asking what is wrong with it often surfaces something the in-editor loop keeps missing.
Habits that prevent most errors
- Keep a Knowledge Base entry describing the project, the stack and the rules you never want broken. It gets read on every prompt.
- Use Plan mode for anything touching multiple files. A plan costs less than an incorrect build plus its fix.
- Publish working versions often so you always have a known good state to return to.
- Describe changes at the level of behaviour, not implementation. "Users should only see their own bookings" is a better prompt than "add a filter to the query".
- Test on a phone before you call something finished. Half of all reported bugs are layout issues at small widths.
If credits are the constraint while you learn all this, the free credits guide explains the daily allowance and how to get more without paying.
Frequently asked questions
Does a failed fix cost credits?
Build attempts consume usage, which is why a precise error report is worth the extra thirty seconds. Check the current credit rules on the pricing page, since the details change.
Can I edit the code myself instead of prompting?
Yes. You can view the code, connect the project to GitHub and edit files directly. For a one line typo that is often faster than describing it.
Why does the same prompt give different results?
Language models are not deterministic and your project changes between attempts. That is also why reverting to a clean state before retrying works better than stacking attempts.
When should I stop and ask a developer?
When the error involves payments, authentication edge cases or data belonging to other people. Everything else is fair game to work through yourself.
