It ran perfectly inside Bolt's browser preview. You deployed it to Netlify, sent the link to your investors, and it immediately threw a white screen. Or it worked for your test account but broke the moment a real user signed up. Or every new prompt is making things worse, and you are starting to think the AI is trolling you.
It is not. This is the predictable failure mode of Bolt.new once a project grows past the size the model can hold in context at once. The Bolt preview environment is not the same as a real deployment, and that gap causes a specific category of breaks that no amount of prompting will resolve. Here is how to diagnose what is actually wrong in the next five minutes, what you can safely attempt yourself tonight, and when it is time to call in someone who can read the codebase the model built.
Diagnose it: six symptoms, six causes
Find your symptom in the left column. The middle column is what is almost always happening underneath it. The right column tells you honestly whether you can fix it without help.
| Symptom | What it usually means | Can you fix it yourself? |
|---|---|---|
| Works in Bolt preview, breaks on Netlify or Vercel | Bolt's browser-based preview (WebContainers) is not a real Node.js environment. Environment variables, file system access, and backend services behave differently once you deploy to an actual server. | Sometimes. Checking that your environment variables are set in the Netlify dashboard is a good first step. Server-side runtime mismatches need an engineer. |
| Breaks the moment a second user signs up | Supabase Row Level Security is disabled or has no policies, so user data collides or leaks between accounts. Bolt rarely configures RLS correctly without being explicitly prompted to. | No. Writing correct RLS policies requires understanding your schema and auth model in combination. Guessing creates data leaks. |
| Every prompt fixes one thing and breaks two others | The model's context window is exhausted. Bolt can no longer hold the full project in view, so every edit patches the symptom it can see while disrupting code further away that it cannot. | No. More prompting accelerates the damage. See the two hour rule below. |
| API keys visible in browser dev tools | Secret keys are embedded in the frontend bundle. Bolt runs in a browser and defaults to client-side code, which means secrets can end up shipped to the browser unless the architecture is explicitly server-side. | Partially. You can rotate the keys today. Moving them server-side safely requires restructuring the app. |
| Database rows readable by anyone | Row Level Security again, and this one is urgent. Your Supabase public API key is in the frontend by design. Without RLS policies, any visitor who finds that key can read entire tables. | No, but run the triage checklist below immediately. This is not a future problem. |
| Data disappears between sessions or users | Bolt prototypes sometimes store state in memory or local browser storage rather than a real database. What looks like persistence in the preview resets when a real user closes the tab. | Rarely. This is an architectural issue: the data layer needs to be rebuilt, not patched. |
The two hour rule
If you have been prompting in circles for more than two hours on the same break, stop. The problem is architectural, and no prompt will fix it.
Bolt, like every AI app builder, works inside a context window. Early in a project, the whole codebase fits inside it, so fixes are accurate. Once your project grows past that threshold, the model patches what is directly in front of it and cannot see what it is disrupting in the rest of the file. Every patch adds new code, new state, and new surface area for the next failure. You are not converging on a solution. You are compounding the problem at a cost of tokens per iteration.
The 20 minute triage you can do yourself
Before you pay anyone, run these four checks. They cost nothing, they require no code changes, and they tell you exactly how serious the situation is.
- Check your Supabase RLS settings right now. Log in to Supabase, open your project, and look at the policies view for each table. If any table holding user data shows RLS as disabled, or shows zero policies, that data is effectively public. This is the single most common security problem in Bolt apps, and it is completely invisible from inside the app itself.
- Inspect your deployed app in browser dev tools. Open the Network tab in Chrome or Firefox, load your app, and look at the request headers and responses. If you can see a Supabase key, an OpenAI key, or any other secret token in a network request or in the page source, treat it as already compromised and rotate it immediately. Keys in the browser are public keys.
- Open your API endpoints logged out. Open a private browser window with no active session and paste the URL of one of your data-fetching endpoints. If data comes back, it comes back for anyone on the internet. A login screen in the frontend is a curtain, not a lock. Real access control lives on the server or in the database.
- Download your data before you do anything else. Export your tables from Supabase as CSV files and keep a copy locally. Whatever happens next, your customer records and content survive. Data loss is the only thing that cannot be undone.
If the first two checks came back clean, you may genuinely be dealing with a deployment configuration issue rather than a security one. If either failed, you have a security problem first and a bug second, and the order in which you fix them is not optional.
What a rescue actually costs
Honest numbers, because you are going to get quotes from all directions. Across the global market, specialist rescue work on Bolt-built apps that need to reach production typically lands somewhere in the USD 2,500 to 6,000 range for a standard project. That is a market observation, not a quote specific to your app. Yours might sit under or well above that band depending on what the audit finds, and anyone who names a fixed price before looking at the actual codebase is guessing.
The tempting alternative is a very cheap generalist freelancer. It usually backfires. Most do not have the depth in Supabase, Next.js, or the deployment stack that Bolt generates to understand what the AI actually built. They end up rebuilding from scratch without fully understanding the original, and you pay twice.
What actually moves the cost is the state of the project before rescue work begins:
- No version control. Bolt does not enforce git history. If there is no commit log, every diagnosis starts from scratch with no record of what changed or when.
- Exposed secrets. Every leaked key has to be rotated across every connected service, and anything those keys touched has to be audited.
- Schema chaos. Duplicate tables, missing foreign keys, and data migrations all add time before the app can be stabilised.
- Compliance requirements. Health data, payment card data, or anything involving children raises the bar on what "fixed" has to mean.
If you have realised that what you really have is a validated idea deserving a proper foundation, that is a different conversation about custom app development, not a rescue.
What a professional rescue actually does
A genuine rescue is not "find the bug and close the ticket." It runs in a specific order, because building features on top of a broken foundation just breaks the features:
- Security audit first. Read the full codebase, map every exposed key, open endpoint, and unprotected table before touching anything. The findings go into a fixed-scope report so you know exactly what is broken before you commit to the work.
- Secrets rotated and moved server-side. Every leaked or suspect key replaced and moved out of the frontend where it belongs.
- RLS and proper server-side auth. Row Level Security policies written for your actual data model, and authentication enforced at the server layer, not the UI layer.
- Version control and CI. Git history established so no future change can silently break something without a record. Automated tests so "it works in preview" starts meaning something.
- Proper deployment pipeline. A staging environment that mirrors production so you catch issues before real users do.
- Then your feature list. Deliberately last. On ground that can actually hold it.
This is also the approach we take on our vibe code rescue service, which covers apps built with Bolt, Lovable, Cursor and v0. If you built with a different tool, read the Lovable rescue guide for the same structure applied to that stack.
Frequently asked questions
Can Bolt fix its own broken app?
Sometimes, for small isolated problems. But if you have been prompting for more than two hours on the same break, the honest answer is no. Bolt generates code from a limited context window and cannot hold a large project in view all at once. Each patch is made partially blind, which is exactly how one prompt repairs login and breaks checkout. Architectural problems need a human who can read and reason about the whole codebase.
Should I start over or fix what I have?
Fix what you have, in most cases. Your app encodes product decisions and validated ideas that took real time to develop, and a rebuild discards all of that along with your momentum. Starting over only makes sense when there is no recoverable code, the database schema is unsalvageable, or the app is small enough to rebuild in a day or two. A good rescue preserves the product you built and replaces what is broken underneath it.
How long does a Bolt app rescue take?
For a typical Bolt app with a Supabase backend, one to three weeks. The first priority is the security audit and secret rotation, because exposed keys cannot wait. Auth and Row Level Security are usually stable within the first week. Tests, CI, and proper deployment follow, and then feature work restarts on solid ground. Schema issues and compliance requirements extend the timeline.
Do I need to stop using Bolt?
No. Bolt is a genuinely fast tool for getting ideas in front of users. The problem is running real customers and their data on prototype infrastructure that was never designed to hold it. After a rescue, many founders keep using Bolt for prototypes and landing pages while the production app lives in a proper repository with version control, tests, and staged deploys. Right tool, right stage.