Outgrowing Bolt: Turning a Fast Prototype into a Product

Bolt is built for speed. It takes a founder from an idea to a working, published web app with no local setup and no separate hosting account. The moment to look past it is rarely a crash. It is quieter than that. The first paying customers arrive, an investor asks who reviews the code, or a feature takes ten prompts and breaks two others on the way. The prototype did its job. The question now is whether it can become the product.

What Bolt Gives You

Bolt is built by StackBlitz and runs on WebContainers, a technology that runs a full development environment inside your browser tab. There is nothing to install, and the preview shows the current state of the app as you build it. Bolt focuses on JavaScript: any frontend framework that runs in the browser, with Node.js for the backend.

Around that editor sits Bolt Cloud. A project can get a built-in database with sign-in, file storage and server functions. Publishing puts the app on a bolt.host address in about a minute, and paid plans can attach a custom domain. The Stripe integration creates server-side functions for checkout, registers the webhook endpoint and verifies its signatures. On paid plans, a security audit before you publish looks for users who can reach other users' data and for private keys that leak into the browser.

Most important for a migration: a Bolt project is real source code, not a proprietary visual canvas. You can download it as a zip, or connect GitHub and get a private repository that Bolt commits to after every change that doesn't break the project. That is a better starting point than most no-code tools leave behind. We are not reverse-engineering a black box. We are reading code.

What Starts to Strain as Real Users Arrive

AI-generated prototype code often grows one prompt at a time. Each request adds a table, a component or a function that solves the problem in front of it. Nobody steps back to ask whether the data model still makes sense. Business rules, such as who can see an invoice or when a trial ends, end up spread across React components, database policies and server functions. A prototype built this way usually has no test suite, no versioned schema migrations and no staging environment, so every change goes straight to the only copy of the app.

Bolt's own docs are clear about how its loop scales. Usage is metered in tokens, and its docs say most of that usage comes from reading, understanding and syncing your project files, so larger projects use more tokens per message. Chat history lives in a context window. Large files fill it quickly, older messages can drop out, and the docs advise you to restate a detail when it matters again. On a small app, none of this is a problem. On a codebase with forty screens and a dozen integrations, the cost of each change climbs, and so does the chance that an earlier constraint is no longer in view.

How We Migrate a Bolt App

Because the code already exists, a Bolt migration is less a rebuild from screenshots and more a careful promotion of a prototype. It follows the same three steps as every First Radicle project. In the Handover, you give us the repository or zip, access to the database, and a walkthrough of how the app should behave. Together we agree on the scope of the six-week sprint. In the Cultivation, we build, with a demo on a staging server every week. In the Harvest, the GitHub repository and the cloud account are yours.

• Inventory before change: We map every route, component, server function and table, and we write down where each business rule actually lives. Most surprises in a migration come from logic that sits somewhere nobody expected.
• Schema and migrations: We design a PostgreSQL schema with foreign keys, constraints and indexes, and keep it in versioned migrations in the repository. Your data comes across through scripts we can re-run, either from a Bolt Database table export or from the Supabase project you chose or claimed. We rehearse the import on staging before the real cutover.
• Auth and authorization review: Sign-in is the easy part. The hard part is the rule that says which user may read or change which row. We enforce those rules on the server and cover them with tests, so the browser can never grant access on its own.
• Logic moves server-side: Prices, entitlements, state changes and every call that needs a secret key move into a Node API. The React frontend renders. The server decides.
• Payments and background jobs: We verify Stripe webhooks, record each event so it is processed once, and move email, retries and scheduled work onto a job queue. A slow third-party service then delays a task instead of failing a request.
• Tests and CI: Tests cover the flows that make money or protect data: sign-up, checkout and permission boundaries. Every pull request runs them before it can merge.
• Observability, secrets and cost: Structured logs, error tracking and uptime checks go in before launch. Secrets live in your host's secret store and are rotated at cutover. We set spending alerts on your cloud and API accounts, so a bill never surprises you.

What Changes in the Migration

Signs You Are Ready to Move

If you are still finding out whether anyone wants the product, stay in Bolt. It is the faster and cheaper place to learn. The signs that you have moved past that stage are practical. You restate the same rule in prompt after prompt. A fix to one feature breaks another. Each change costs more tokens as the project grows. You need a backend language other than JavaScript. A customer or investor asks about tests, access control or who owns the infrastructure. Or you are about to hire an engineer who expects pull requests, not a chat window.

Two or more of these usually mean the prototype has done its job. You keep everything it taught you: the screens, the flows and the data your users created. The next stage needs a codebase that a team can read, test and change with confidence.