When a Lovable or Base44 app stops working, one of three things is broken, and they need different responses. Either the builder is stuck, the app it wrote is failing, or the app is fine and you are looking at the wrong copy of it: a stale published version, or the one your browser saved last week. Nearly every “not working” story is one of six causes, and each has a tell you can spot in a minute without reading code.
First, find out which of the three is broken
Check the builder before you blame your app. Both companies run a public status page, at status.lovable.dev and status.base44.com, and when the platform is having an incident, every app looks broken at once. If it is red, nothing you type will help, and every message costs credits anyway.
Then check the copy. Open your app’s live address in a private browser window, where nothing is saved and you are logged out. If it works there, your browser was showing an old copy, which both vendors’ troubleshooting pages tell you to rule out. If it is still broken, the problem is in the app or in something it depends on, and the sections below are for you.
The screen is blank or white
A white screen means the page’s program hit an error before it drew anything. Most apps built by these tools are one program that runs in the visitor’s browser and paints the whole screen, so a single early failure leaves nothing to look at. The part of the app that would have shown you a message is the part that never ran.
Lovable’s preview has a Refresh button, and holding Shift while clicking it restarts the preview environment, which its docs say resolves most loading problems. When the failure is in the code, Lovable shows a build error with a Try to fix button that scans the logs and attempts a repair. Base44 lists three causes for a blank app: a problem in the code, a temporary platform issue, or a failed deployment. For a screen that goes white when you click something, it points to the Revert icon and to Version History.
One pattern fools people: the app is white only for visitors who are not logged in. A page asks for something only a logged-in person has, gets nothing, and crashes on the nothing. It works for you because you are always logged in. Base44’s docs put it plainly: an app without login cannot tell who a visitor is, so features that depend on identity will not work.
It works in the preview but not on the live address
This is the “published app not updating” family, and it is not a bug. In Lovable, publishing takes a snapshot. Its docs say changes are not pushed to your live app on their own: you open the Publish dialog and click Publish changes, and a small dot appears on the Publish button whenever your project is newer than the live version. Accepting a draft is not publishing either. Both share one backend and database, so the data matches even when the screens differ.
Base44 works the same way. The preview on the right updates as you edit, and the live site changes when you click Publish in the top bar. Its troubleshooting page adds three reasons published changes fail to appear: a cached copy in your browser, a deployment problem, or a publish step that never finished, and it says to confirm the success message and check from a second device.
Stuck on “thinking”, or the chat has gone quiet
The chat is a window onto a long job running on the builder’s servers. When that job dies or your connection to it drops, the window keeps showing its last state, which is the word “thinking”. Base44’s advice is specific. A complex first build can take ten to fifteen minutes, so wait that long before acting. If nothing has changed by then, press Stop. On a first prompt the app has often been partly created, and Base44 suggests cloning it from its settings or starting a fresh app with the same prompt, split into smaller requests. For a chat that will not respond at all, it blames a long prompt, a browser or network problem, or a platform update.
Lovable handles the same moment differently. When it is unsure, it can pause and show a question card instead of guessing, so a “stuck” build may be waiting for you to answer. And when an error keeps coming back, its docs say not to send the same prompt again but to revert to the last working version and describe the problem more precisely, or to use plan mode, which writes out its plan before touching anything.
It worked yesterday and stopped today
Four things change overnight. Your credits ran out: on Lovable the published pages keep serving, but AI features inside the deployed app stop, and apps that rely on the built-in backend can pause when the workspace hits zero. A change you made broke it: both builders keep a version history, and Lovable’s docs note that reverting restores the code but never the database data. A service your app depends on failed: the AI model, the database, a payment provider, and the status pages only cover the platform’s own pieces. Or nothing changed at all, and the app has been failing silently the whole time, and today someone finally tried the path that fails.
That last one sits underneath most of the six. An app that only knows how to succeed shows nothing when a request fails: no message for the user, no record for you. A bigger prompt will not fix that. What fixes it is an app that expects failure, tells the person something calm and true when it happens, and writes down the detail somewhere you can read later, so that “not working” turns into a specific sentence you can act on.
You can learn more, and get the full prompts and the decision tables, in our course: Lesson 8, The Silent Crash. The first lesson is free, no card.
In the next ten minutes: open the status page, then open your live address in a private window. If it works there, publish your changes and reload. If it is white, check whether it is white for everyone or only when logged out. If the chat is stuck, wait, press Stop, and open the version history. Then write down which of the six it is. That sentence is the message the builder needs next.