Can Bolt.new build production apps in 2026?

Bolt.new is one of the most impressive AI coding tools of the current generation. It runs the entire development environment in a browser tab via StackBlitz's WebContainer tech, which means you watch the app build and render live as you prompt. It does not feel like a demo; it feels like programming with a very fast pair.

But “impressive” and “production ready” are different standards. A lot of founders ship a Bolt prototype to a handful of beta users, see it work, and assume they are ready for public launch. They are not. The gap between those two states is predictable, specific, and well documented across the forty plus Bolt apps we've audited. This is an honest review of where Bolt delivers and where it stops short.

1. What “production-ready” actually means

Before we evaluate Bolt, we need a working definition of production. A production app is one that can accept real users without losing their data, taking their money incorrectly, or leaking other users' information. That bar is low, but it is surprisingly hard to clear with AI generated code.

Concretely, a production app needs:

• Authentication that works on the production domain — not a preview URL, not localhost, not a staging subdomain that looks similar. OAuth redirects must land where they are supposed to.
• Row-Level Security or equivalent authorization that prevents one authenticated user from reading another user's data. Client-side filtering is not a security boundary.
• Webhook handlers that are idempotent, handle every event type, and verify signatures. Money flows through webhooks; getting them wrong is expensive.
• A deployment pipeline that can push updates without downtime, and a rollback procedure that you have actually tested before you need it.
• Error monitoring that alerts you before users report problems — Sentry or equivalent — and structured logs you can actually query.
• Basic performance hygiene: indexed foreign keys, no obvious N+1 queries on hot paths, a CDN in front of static assets.

An app that covers all of those is production ready at the minimum bar. Missing any one is a live liability. Missing several — which is the typical Bolt prototype state — means you should not be charging real customers yet.

2. What Bolt does well

It is easy to focus on the gaps; let's start with the real strengths, because Bolt has genuine ones.

Fast iteration on UI.Bolt's WebContainer means you see every change render in real time. Compared to a local Next.js project with hot reload, Bolt is slightly faster because there is no file system latency. Compared to iterating in a traditional IDE with a CI preview, it is much faster.

Good React component generation. Bolt output is syntactically clean, uses modern React patterns (hooks, server components where applicable), and is not littered with the weird anti-patterns that show up in some AI code. It uses Tailwind sensibly and does not invent className conventions.

Full-app scaffolding. Unlike v0, which generates components only, Bolt generates a full app including routing, state management, and backend integration. You end a Bolt session with something that walks and talks like an app, not a collection of UI pieces.

Expo support for mobile. Bolt can target Expo for iOS/Android, which most competitors do not attempt. The output is imperfect but usable as a starting point — considerably better than trying to port a Lovable or v0 web app to mobile by hand.

Validation speed.If the question is “is this product idea worth building,” Bolt is excellent. You can get a functional clickable demo in an afternoon, put it in front of five users, and learn. For that use case, Bolt is genuinely near the top of the category.

3. Auth: partially production-ready

Bolt wires up authentication reliably, but only partially for production. If you ask it to add Supabase Auth to an app, it will create the sign up page, the sign in page, the forgot password page, and the supporting client code. In the preview environment, all of this works.

The gaps show up when you deploy:

• OAuth redirect URLs default to the StackBlitz preview URL. Moving to production means updating them in the OAuth provider dashboard (Google, GitHub) and in the Supabase Auth settings — Bolt does not do this for you.
• Password reset email templates point at the preview URL. Users receive an email, click the link, and land nowhere. This is a small fix but an easy one to miss until a real user has already hit it.
• Session refresh handling is often incomplete. Bolt does not always install the middleware that refreshes Supabase sessions on every request, which means sessions expire unexpectedly and users are bounced to login mid task.
• Email verification is usually disabled in the scaffolded version. Anyone can sign up with any email address, including typos and throwaway domains. For a real SaaS with paid tiers, email verification is not optional.

None of these are hard to fix. Together they represent roughly four to eight hours of work for an engineer who knows what they are doing. The problem is that the app looks like auth is done — the flows run in preview — so the fix is often delayed until users hit the issues. Verdict: Bolt auth is production capable, but not production ready at handoff.

4. Database and RLS: not production-ready by default

This is the single biggest production gap in Bolt output, and it is the same gap that Lovable, v0, and the other AI builders share. Bolt uses Supabase well for CRUD operations — it generates tables with sensible schemas, writes reasonable queries, and uses the Supabase client correctly. What it does not do is enable Row-Level Security.

When Bolt creates a Supabase table, the default is RLS disabled. When RLS is disabled, any client holding the anon key — which is every browser visiting your app — can read every row in the table. If your app has a projects table with user_id, any authenticated user can run supabase.from('projects').select('*')and get every other user's projects. That is not a theoretical risk. The widely-reported February 2026 Lovable/Supabase RLS disclosure captured exactly this failure pattern at scale.

Bolt also uses the anon key uniformly for all operations, including operations that should require user context or the service role. Some of these work anyway because of defaulting logic, but the patterns are fragile and the permissions model is opaque to a non technical founder.

The fix: enable RLS on every table, write per table policies that check auth.uid() = user_idon SELECT, INSERT, UPDATE, and DELETE, and test each policy with a real user token. Write integration tests that assert user A cannot see user B's data. For shared resources (teams, organizations), write policies that check membership through a join. None of this is hard; all of it is essential; none of it is done by default.

5. Stripe: 30% production-ready

If you ask Bolt to integrate Stripe, you will get a checkout session creation function and a success redirect page. That is roughly 30 percent of a working Stripe integration. The other 70 percent is not optional, and Bolt does not generate it.

What Bolt generates:

• A server-side function that creates a Stripe Checkout session.
• A button that redirects to the returned Checkout URL.
• A success page that reads the session_id query parameter.

What Bolt does not generate, and what you cannot ship without:

• A Stripe webhook handler. Without a webhook handler, you cannot confirm payment server side. The success redirect is not a confirmation — a user can trivially hit /success without paying.
• Signature verification. A public webhook endpoint with no signature verification can be POSTed to by anyone. An attacker can fake a checkout.session.completed event and grant themselves premium access.
• Handlers for failure and lifecycle events: invoice.payment_failed, customer.subscription.deleted, customer.subscription.updated. Without these, users whose card fails retain access; users who cancel keep access; upgrades and downgrades do not reflect in your database.
• Idempotency. Stripe delivers events at-least-once. Your handler must ensure processing the same event twice produces the same result. Bolt-generated code rarely addresses this.
• Customer portal integration. Users cannot manage their own subscriptions (update card, cancel, upgrade) without this, so every such request becomes a support ticket.

Verdict: Bolt's Stripe integration covers the happy path of initial checkout. Everything after the first successful payment — which is most of the subscription business — requires the engineering you thought you were skipping.

6. Deploy: capable but manual

Bolt apps can be deployed to Netlify or Vercel without rewriting large chunks of code. The main friction is the gap between what works in the WebContainer preview and what works on a real host.

Common deploy issues:

• StackBlitz-specific module paths or import patterns that do not resolve outside the WebContainer. Usually a small set of files that need path adjustments.
• Environment variables that were defined in the Bolt preview but have not been migrated to the host's env var settings. Build fails with cryptic errors until each missing var is added.
• Build configuration (Vite, Next.js) that references features or paths specific to the preview environment. Most common with Vite-based Bolt apps; Next.js outputs are usually cleaner.
• Edge function or middleware code that behaves differently between the preview runtime and the production runtime. Session handling is the usual victim.
• Stripe webhook endpoints registered against the preview URL rather than the production URL, so events never arrive once you switch domains.

None of these are blockers. An engineer familiar with Next.js or Vite can move a Bolt app to a proper host in a day. For founders without that experience, it is a stumbling block that can take a week or more of back and forth with the AI, often with increasing confusion as the prompts accumulate. Verdict: deploy is achievable, but it is not the one click experience the Bolt preview implies.

7. The verdict: when to use Bolt for production

Pulling the previous sections together into a recommendation:

Bolt is production-ready for:

• Simple content sites and marketing pages that do not handle user data or payments.
• Internal tools used by five to ten known users where security-via-obscurity is acceptable and RLS is not a hard requirement.
• Single feature apps with no payments, no multi-user data sharing, and no regulatory surface.
• Early stage prototypes explicitly for user research, on the understanding that you will rebuild the backend when the idea proves out.

Bolt needs developer hardening for:

• Any SaaS with paying users and recurring subscriptions.
• Apps handling personal data, health data, or financial data.
• Apps with Stripe subscriptions that need anything beyond “checkout works once.”
• Apps with multi-tenant data isolation (organizations, teams, shared workspaces).
• Anything that will have more than a hundred users in the first year.

The typical successful Bolt to production pattern we see: use Bolt to prototype, validate the idea with five to twenty users, then run a hardening pass (ours or another engineer's) before opening the app to the public. The hardening pass catches the RLS gap, completes the webhook surface, fixes the auth redirect URLs, adds error monitoring, and writes the first integration tests. That pass is a week or two of focused work and is significantly cheaper than debugging in production.

The failure pattern we see: founders skip the hardening pass, launch, hit an incident within four to twelve weeks, and call us from a position where the codebase has accumulated another month of AI-generated changes on top of the original issues. That version is more expensive to fix because the scope is larger and the founder is under pressure.

Bolt is a good tool. Treat it like the prototype tool it is, ship only what it is ready to ship, and bring in an engineer for the rest. The combination works; either half alone does not.

See how rescue works →