Bolt.new Not Working? What to Check Before Starting Again

When Bolt.new is not working, the tempting answer is to start again or ask for another broad fix. That can help with a simple prototype, but it can also hide the real fault. A broken Bolt.new app might have a frontend error, a missing package, a Supabase rule, an environment variable problem, a failed deployment or a route that only breaks outside preview.

Start by separating the symptom from the cause

Write down exactly what fails. Does the preview fail to load? Does one page show a blank screen? Does login fail? Does the app work in Bolt.new but break after deployment? The more specific the symptom, the easier it is to avoid changing the wrong part of the project.

If you need a technical review, the Bolt.new app repair page explains what to send for diagnosis.

Check preview, shared app and live deployment separately

Bolt.new preview and production are not the same environment. If preview works but the live app fails, look at build logs, environment variables, redirects, routes, hosting settings and external service domains. If preview and live both fail, the fault is more likely to be in generated code, dependencies, shared config or connected services.

Read the first real error, not every warning

Open the browser console and network tab. Look for the first error in the chain. One missing variable or failed request can produce several follow-on warnings. Fixing the warnings before the first failure wastes time and may create more code churn.

Check dependencies and run commands

Generated apps can include missing packages, incompatible versions or scripts that work in one environment but fail elsewhere. Check whether the install step completes, whether the build command is correct and whether the app depends on a package that was added during a later AI fix.

Check Supabase, auth and environment variables

If your app uses Supabase, check the URL, anon key, service-side secrets, auth settings, redirect URLs and row-level security policies. Missing production variables can make a live app fail even when the preview looked fine.

Know when to stop prompting

If every prompt fixes one error and creates another, pause. The project may need root cause diagnosis rather than more generated changes. If the issue is unstable generated code, AI code repair may be the safer route.

Practical checklist

• Record the exact page, action and error.
• Check whether preview, shared app and live deployment behave differently.
• Read console and network errors.
• Check build logs and package installation.
• Check environment variables and Supabase settings.
• Stop if prompts keep creating new faults.

Conclusion

Bolt.new can help you build quickly, but repair work still needs a calm diagnosis path. Find the layer that is failing before you spend more time rebuilding or prompting around the wrong problem.

What a repairer will usually ask for

Useful details make the repair faster. Send the preview URL if you have it, the deployed URL, the exact action that fails, the first console error, any failed network request and the last prompt or deployment before the issue started. If Supabase is involved, say whether the fault affects auth, tables, storage, functions or policies.

Do not worry if you cannot interpret every error. The point is to preserve the evidence before another prompt changes the code. A short, specific report is more useful than a long list of guesses.

When starting again is the wrong move

Starting again can feel cleaner, but it may recreate the same problem if the root cause is a production setting, an auth callback, a database policy or a missing environment variable. Rebuilding is only useful when the current structure is genuinely fragile. Diagnosis helps you make that decision with evidence.