Bolt to production: turn fast browser momentum into a real release

Bolt apps most often stumble where browser optimism meets shared state: duplicate form submissions, permissive database rules, client-exposed keys, and an edge function that assumes every request is friendly. Build-time environment drift and missing error boundaries follow. We also look for race conditions hidden by a fast local connection and third-party quotas that were never part of the demo.

It means Bolt’s exported source has a repeatable build, locked dependencies, secret injection outside the browser, and a documented deployment owner. Authentication must enforce server-side authorization; data needs migrations, backups, and tested restore; CI should run type, unit, integration, and security checks. If a mobile wrapper is planned, add privacy, signing, deep-link, and store-review gates before calling the web prototype a product.

Harden when the component structure, user journey, and data concepts are still economical to support. Rewrite a boundary when generated code has duplicated business rules, the schema cannot express ownership, or infrastructure assumptions cannot be tested in CI. We keep the useful interface and rewrite the narrowest risky seam first—usually auth, payments, or a write-heavy workflow—rather than rewarding anxiety with a total rebuild.

First value is not “the preview loads.” It is a real user creating an account, completing the central action, seeing a durable result, and being measurable when something fails. We define that slice with a production domain, backed-up data, support breadcrumbs, and a rollback path. Secondary roles, visual refinements, and broad feature coverage wait until that path is boring under normal and degraded conditions.