My AI-Built App Crashed: What to Do When Vibe-Coded Apps Break

A crash is loud. The kind that costs you customers is quiet. Your AI-built app didn’t fall over with a stack trace and a 500 page; it kept serving a clean white screen while sign-ups quietly failed and payments quietly stopped, and the first you heard of it was a refund notification or an email titled “Login broken.” That is what “my app crashed” usually means for a vibe-coded SaaS. Not a crash. A silent stop wearing a working app’s face.

Marcus learned the term the hard way two weeks after shipping his Bolt.new app to its first paying users. The app looked alive. It wasn’t. And before we go further, here’s the one phrase that makes all of this make sense: watching your app from the outside. It means checking the things a real customer touches, the login, the payment, the data load, by actually touching them, instead of trusting what the builder’s preview window tells you. Your AI builder shows you the inside view. The outside view is the only one your customers ever see, and it’s the one that breaks silently.

“Several were made on lovable. It’s not on their users to understand these flaws… and their personal data to get exposed I guess.”

— Hacker News commenter, 2025

If you’re reading this mid-panic, put the coffee down and breathe. Nothing here requires you to read code. You didn’t write it anyway.

Start by going back, not forward

The single move that fixes about 40 percent of these is the calmest one: roll back to the last state where everything worked. When an AI app breaks overnight, the cause is almost always that the agent quietly rewrote a route or swapped out a working dependency while “improving” something you never asked it to touch. Don’t read the new code hunting for the flaw. Go to the project history or version control tab in Bolt, Lovable, or Replit, find the deployment from before things got strange, usually 12 to 24 hours back, and hit revert.

One thing not to do: don’t ask the AI to fix the bug it just made. That’s how you walk into a doom loop, where the agent hallucinates five new problems while patching one, described in full in Bolt.new Doom Loop. Get the app back to the happy state first. Then, with the live app safe, clone the project into a separate workspace and figure out what broke in peace. Related deploy-time failures live in Bolt.new App Works in Preview But Breaks in Production.

Five places to look, calmly, in order

Think of these like checking the rooms of a house after the power flickers. You’re not panicking. You’re just walking through, room by room, seeing which light won’t come on.

Is it down, or just slow? The landing page shows up, but the real interface hangs or spins forever. Open your browser’s developer tools, go to the Network tab, refresh, and watch for any request that takes more than five seconds or times out. Load the app on a cellular connection too, to rule out your own cache. AI generators write pretty interfaces and inefficient queries, and a vibe-coded app will happily fetch the entire database to show one profile name. Fine with three test users. When Marcus crossed 214 paying users, that same query started dragging the whole app to a stall on every page load.

Can people still log in? The marketing page is perfect, but hitting the login button does nothing, or throws a generic “something went wrong.” Open an incognito window, try to make a fresh account, then try an existing test login. If both fail, open your Supabase, Clerk, or Firebase console and see whether login requests are even reaching the server. The Lovable-and-Supabase specifics are in Lovable App Hangs After Login and Lovable Supabase Connection Lost. Worth checking the login before the database, because a broken database tends to throw a loud error, while a broken login button just sits there looking healthy and locked shut.

Is the database still reachable? People log in fine, but their dashboards are empty or blank on load. Go straight to your database provider’s console and read the active-connection and CPU metrics. On Supabase, check whether the project got paused for inactivity or hit a connection limit, then run a simple query in the SQL editor to see if it answers at all. The usual cause: the agent’s code opens a brand-new database connection for every single request instead of reusing them, you hit the provider’s hard limit, and the database shuts its own doors to survive. A useless alert reads Error 1040: Too many connections. A useful one reads Supabase connection limit reached. Your users cannot load any data. You want the impact, not the raw log line.

Did your last AI session break it? One specific feature, PDF export, email, saving settings, stopped working right after your last coding session, and nothing else changed. Look at the diff of your last few prompts. Did you ask for a button color change and get a rewritten routing file? Revert that one change and watch the feature come back.

“I actually ended up incurring some extra Twilio bills due to a bug in the code (we send texts for RSVPs) so I’ve stopped using it.”

— Evantapp on IndieHackers, 2024–2025

AI agents have no strict sense of “leave that alone.” They’ll confidently rewrite a working backend endpoint because they decided it was necessary to center a heading, and since the preview looked fine, you deployed it.

Did a third-party service quietly fail? Payments stop, or you’re suddenly bleeding money on a background task stuck in a loop. Log into your usage panels for OpenAI, Stripe, Twilio, whatever powers the app, and look for sudden spikes or hard rate-limit blocks, expired keys, a declined card on file. Check Stripe’s webhook logs to see whether your app is even responding to payment events. The classic cause is a recursive function pinging a paid API forever, or a key that expired with zero error handling to warn you, failing silently while the server bills climb. Revoke the affected keys to stop the bleed, then find the loop.

The thing you can’t keep doing by hand

You can run every check above. You cannot run them forever, every morning, on an app you built precisely so you wouldn’t have to babysit it. That’s the real bind with a vibe-coded SaaS: the fragility is baked into the foundation, the platform will change something eventually, an agent will break a dependency eventually, and the break will almost always be silent. So the answer isn’t more vigilance. It’s handing the watching to something that doesn’t sleep. NoCrash touches your login, your payments, and your data the way a customer would, from the outside, on a schedule, and tells you in plain language the moment one of them stops, before the refund notification does. Start free at nocrash.io.

None of this is hard once someone’s actually watching. It’s just nobody’s job until a paying user makes it everybody’s emergency. Make it somebody’s job before then.