Bolt Prototype to Production: 20-Minute Launch Self-Test

Why a Bolt demo passes and a live app fails

Bolt writes a standard web project. You can push it to GitHub or download it as a zip. Projects that need a backend run on Supabase, which gives you a Postgres database, login, file storage and edge functions. All of these run in production every day. The tools are rarely the problem. The settings are. A prompt that asked for "a working login" never asked for "each user can only see their own data." Your demo passes because you are the only user. Real users behave differently. Strangers sign up. Someone edits an ID in the URL. A customer asks for a refund. The test below copies those moments.

Is my Bolt app ready to launch? The 20-minute self-test

You need two browsers (or one normal window and one private window), your app's live URL and access to your Stripe dashboard if you charge money. Write down every step that fails. That list is your starting point, whatever you decide next. Prefer a scored checklist? The AI App Production Readiness Score gives you a score out of 100 across security, performance, deployment and more, plus an action plan. The steps:

• 1. Create two accounts, A and B, one in each browser.
• 2. As A, create something private: a note, an order, a profile. Copy its URL or ID.
• 3. As B, open that URL. If B can see A's data, your database access rules are broken.
• 4. Open your browser's developer tools and search the loaded files for "service_role", "sk_live" and "sk_test". Any match means a secret key is public.
• 5. Request a password reset from a private window. Check that the email link opens your real domain and works.
• 6. Pay in Stripe test mode, then refund that payment in Stripe. Check that the app removes the paid access.
• 7. As B, paste the payment success page URL without paying. If B gets premium, anyone can.
• 8. Answer two questions honestly: is the code on GitHub, and is there a separate test database from the one live users would hit?

What each failed step means

A short reminder of what sits behind each result. The full, ordered fix plan is already covered in our AI prototype to production guides. For the platform side of Bolt (sandbox, export, hosting), see Bolt to production.

• 3. B sees A's data. What it usually means: Row Level Security is off, or a policy lets any logged-in user read every row.
• 4. Key found in the browser. What it usually means: a secret was put in a "VITE_" variable and bundled into the frontend. Move it server side and rotate it.
• 5. Reset link broken. What it usually means: Supabase auth still points to the preview URL.
• 6 or 7. Access not removed, or free premium. What it usually means: access is granted on a redirect instead of Stripe webhooks.
• 8. No GitHub, one database. What it usually means: no history, no migrations, no safe way to change the schema after launch.

Bolt prototype to production: harden or rebuild?

Once you have your list of failed steps, the real question isn't "how many problems?" It's "what are they sitting on?" Five broken settings on a sound data model is a fix list. One wrong data model under everything is a rebuild. Check each signal below and see which side your prototype matches.

• Data model. Points to harden: tables match your product, each row has an owner. Points to rebuild: user data mixed together, no owner on rows.
• Access rules. Points to harden: missing but easy to add. Points to rebuild: logic depends on hiding data in the frontend.
• Code. Points to harden: clear components, on GitHub. Points to rebuild: the same logic copied across many screens.
• Payments. Points to harden: Stripe checkout exists. Points to rebuild: payment state stored only in the browser.
• Platforms. Points to harden: web is enough for now. Points to rebuild: you now need iOS and Android apps too.

When hardening makes sense

Harden when most of your answers land on the harden side. You keep your screens, your design and the work you already put in. You fix the failed steps in the right order: lock the data first, then login, then payments.

When a rebuild is the cheaper path

Rebuild when the data model is wrong. Every fix you make on top of a bad schema has to be redone later, so patching often costs more than starting the core again. The same goes when your plan has changed and you now need native mobile apps alongside the web.

A quick example of each

A booking app where every booking row has a "user_id", but Row Level Security was never switched on, fails step 3. That's a hardening case: the structure is right, the rules are missing. A marketplace where buyers and sellers sit in one table, and the app decides who sees what by hiding fields on screen, also fails step 3. That's a rebuild case: adding rules means changing the structure underneath them. Not sure which side you're on? Book a call and bring your Bolt link. It's a free 30-minute call, and you get a fixed quote before we write any code.

What it costs to get a Bolt app to production

We can't give you a single price for hardening, because it depends entirely on what your test finds. A missing auth redirect and a broken data model are very different jobs. The honest way to price it is to look at the code first. That's what our AI-generated code audit does. It takes 1 to 3 days for a small Next.js app and about a week for a multi-tenant SaaS with payments and file uploads. You get a severity-ranked list, from ship blockers to later fixes, a recommended path (harden or rebuild) and an estimate. If a rebuild is the right call and your scope fits a focused v1, it can fit our MVP Development package:

• Fixed at $3,460, with a fixed quote before we start.
• Web, iOS and Android.
• Delivered in around 20 days, with progress shown every week.
• Design included.
• 100% of the code is yours, on your GitHub.
• 2 weeks of fixes after launch.

Is Bolt.new good enough for production?

The code and the Supabase backend can run in production. What usually isn't ready is the setup: access rules, secret handling, login redirects, payment webhooks and separate environments. Run the two-account test above before you launch.

How do I know if my Bolt app is secure?

Start with steps 3 and 4 of the self-test. If a second account can open the first account's data, or a secret key shows up in your browser files, the app isn't safe for real users yet. A code audit goes deeper than any self-test.

Can I export my Bolt code to GitHub?

Yes. Bolt can create a GitHub repository and push the full project, or you can download it as a zip. The result is a standard web project that a developer can run outside Bolt.

Do I need to rebuild my Bolt app from scratch?

Not always. If your data model is right, hardening is usually the better path. A rebuild makes sense when the schema is wrong, when access depends on hiding data in the frontend, or when you now need native mobile apps. Ran the test and found blockers? Book a call and get a fixed quote before any code is written.