6 Bolt.new Problems That Break Apps in Production (And How We Fix Each One)

Bolt.new is one of the better AI app builders for getting from idea to running prototype. The problem is not Bolt. The problem is that "runs in the Bolt preview" and "runs in production for paying users" are different bars, and the gap between them is remarkably consistent across the apps we are asked to rescue. We have fixed enough Bolt.new apps now that the failures rhyme. Here are the six we see most, in roughly the order they bite, with the fix we actually apply for each.

1. Environment variables that only exist in the preview

The most common reason a Bolt app works in the preview and breaks on deploy is environment configuration. Bolt holds your keys in its environment, and the generated code reads them directly. When you export and deploy to Vercel, Netlify, or Railway, those variables do not come with it.

The fix: Inventory every key the app reads, set them explicitly in your host's dashboard, and fail loudly when one is missing instead of limping along.

// Do not let a missing key fail silently three layers deep
function requireEnv(name: string): string {
  const value = process.env[name]
  if (!value) throw new Error('Missing required env var: ' + name)
  return value
}

const stripeKey = requireEnv('STRIPE_SECRET_KEY')

2. Authentication that protects the screen, not the data

Bolt builds a clean login flow. What it usually does not build is server-side enforcement on the endpoints behind that flow. The UI hides the dashboard from logged-out users, but the API that feeds the dashboard will still answer a direct request.

The fix: Enforce identity and ownership on every protected endpoint on the server, not in the component. This pattern is identical across AI builders, and we break down the exact failure and fix in Why AI-Generated Authentication Always Breaks.

3. A data model with no constraints

Bolt-generated schemas tend to make everything optional and enforce nothing. No foreign keys, no NOT NULL, no checks. It works in the demo because you, the careful creator, only ever entered clean data. Real users do not.

The fix: Add the constraints the app actually depends on, then clean up the rows that violate them. Adding a foreign key or a NOT NULL will fail against bad existing data, which is exactly how you find the corruption that is already there.

4. Token limits quietly degrading the build

This one is specific to AI builders and catches people off guard. As your app grows past Bolt's context window, the model can no longer see the whole codebase when it makes a change. It starts editing in the dark, reintroducing bugs you fixed, duplicating logic, and breaking patterns it set up earlier.

The fix: Treat the token wall as the signal that the app has outgrown the builder. That is the moment to export to a real repository and work in a normal editor with full-codebase context. If you are at this point, the vibe-code-to-production migration playbook is the next thing to read.

5. Deploys that succeed but ship a broken app

Bolt apps frequently build fine and then 500 on the first real request. The usual culprits are server-only code that assumed the preview runtime, hardcoded preview URLs, and database connections configured for Bolt's environment rather than your production database.

The fix: Do a real deployment dry run against a staging copy of production. Point at the production database, use production URLs, and walk the critical flows before you send a single customer to it. The preview passing tells you almost nothing about the deploy.

6. No error handling on the unhappy path

Generated code handles the case where everything works. It rarely handles the network call that times out, the payment that declines, or the upload that fails halfway. In the demo nothing fails, so the missing handling is invisible. In production it shows up as a frozen screen and a confused customer.

The fix: Add error handling and user-visible fallbacks on every external call, especially payments, third-party APIs, and file uploads. Every async boundary needs a plan for failure, not just success.

Key takeaways

• Set every environment variable explicitly on your host and fail loudly when one is missing.
• A login screen is not security. Enforce ownership on the server for every protected endpoint.
• Add real database constraints, then fix the bad data they surface.
• The token wall is your cue to export Bolt to a real repo and keep building there.
• Test the deploy against a production-shaped environment, and handle the unhappy path on every external call.

None of these are reasons to avoid Bolt.new. It is a fast way to get something real in front of people. They are the predictable cost of taking that something to production, and every one of them is fixable. If your Bolt app is past the demo and breaking under real use, this list is usually the whole map.