Built with Bolt.new?

Your Bolt.new app runs fine in the preview. The published version doesn't.

Bolt is fast, and the stack behind it is more real than its critics allow: the builder runs your app's code inside your browser tab, while Bolt Cloud supplies a hosted database, authentication and server functions. So why does the published app break? Because publishing is the first production build, the first stranger's browser arriving with none of your state, and the first honest test of every corner a prompt left unwired. The failures that follow cluster in the same six places.

What actually breaks

• Publish is the first production build, and the first stranger to load itThe builder runs your app inside StackBlitz's WebContainer, a Node.js runtime living in your browser tab, served warm by a dev server that rebuilds around you and forgives a lot. Publishing swaps that for a production build: stricter bundling, environment variables resolved at build time, no dev server catching mistakes. It is also the first time a browser carrying none of your session state loads the result. Many apps meet both conditions for the first time in front of a customer.
• Bolt Database exists; the screen you shipped may never have been wired to itBolt creates a database automatically when your project needs one; that part of the stack is real and hosted. The gap appears screen by screen. A feature built before the database existed, or one where you told Bolt to keep things in local storage, holds its records in component state or the browser. In your preview that is indistinguishable from persistence, because you are the one browser that has the data. Every other visitor starts empty. The fix is wiring those screens to the database already sitting there.
• Bolt's Secrets tab does keys right; the audit finds the calls that skipped itBolt's documented path is sound: secrets live in a Secrets tab, server functions read them, and the docs promise keys never end up in users' browsers. Ask it to integrate OpenAI and it will prompt you for the secret. But nothing stops a differently worded prompt putting the fetch call straight into a React component, where it works identically in the preview and ships the key inside the bundle. I search the built output for credentials; anything found gets rotated and the call moved into a server function.
• Bolt deploys Node functions, not the long-running server your prompts may have builtBolt Cloud does host backend code, as server functions: Node.js handlers it runs on servers close to your users. That model has no place for a long-lived Express process holding websocket connections, in-memory sessions or background jobs, and only JavaScript backends are supported at all; Bolt's docs rule out Python and PHP. If your prompts grew that kind of server, it ran in WebContainer and has no production home until it is restructured into functions. Choose the Netlify path instead and the docs are blunter: no database, no traditional backend.
• If you connected Supabase, preview and production share it, and rollbacks skip itBolt's Supabase integration connects your project to a single database: same tables, same keys, whether you are prompting in the builder or serving customers. A prompt that reworks the schema reworks it for live users in the same moment. And Bolt states that its version history does not restore Supabase databases, so rewinding after a bad change brings the code back and leaves the schema exactly where the prompt left it.
• A near-simultaneous GitHub write is resolved in Bolt's favourThe GitHub sync runs both ways: Bolt commits as you prompt and checks the repository every thirty seconds for outside changes, pulling them in. The documented exception is the dangerous part: when both sides update at almost the same time, Bolt keeps its own changes and overwrites the GitHub version. Bolt calls this rare, and it is, until an engineer and a prompter are working the same hour. Merging branches inside Bolt is not supported either; that happens on GitHub.

How I work in a Bolt project

Bolt can push the project into a GitHub repository under your account, and the sync runs both ways: Bolt commits every change it makes and pulls in commits made outside the builder every thirty seconds. That repository is where I work. You give me access, I fix the problem there, in ordinary code, with ordinary tools, and the sync carries it back into Bolt, so you keep the builder afterwards. One rule follows from Bolt's own docs: a near-simultaneous write is resolved in Bolt's favour, so while I am in the repository you pause the prompting and route changes through me; ask and I make them. If you never connected GitHub, we set that up first; it takes minutes.

What “done” looks like

We agree one of these in writing before you pay anything. If it passes, the sprint passed. If it doesn't, you get a full refund and keep the work.

• ✓A record you create on your machine appears for a visitor on a different device signed in as a different user, because it lives in the project's database and not in anyone's local storage.
• ✓Every paid API call goes through a server function, its key lives in Bolt's Secrets tab and nowhere in the built bundle, and any key that ever reached a browser has been rotated.
• ✓The published site, opened on the production domain by a browser that has never touched Bolt, completes the core customer journey end to end with no failing requests.
• ✓Your GitHub repository builds and deploys the exact live site from a clean checkout, so the project survives without Bolt if it ever has to.

Other things that block launches

• Your Lovable app works in the preview. It breaks in production.
• Stripe took the money. Your customer got nothing.
• Your Replit app works in the workspace. The published version doesn't.
• Your v0 app looks ready to ship. The part that breaks is the part you can't see.
• Your Base44 app works when you use it. It breaks when your customers do.
• Your Cursor app runs on your machine. That is the only place it has ever been tested.
• Your customers can see each other's data. It is never just the one screen you found.
• Users can't sign in. It worked every time you tested it.
• It runs on your laptop. It will not deploy anywhere else.
• Your AI feature is impressive when it works. You can't put it in front of a customer.
• The full The Launch-Blocker Sprint