Shimira IT
Bolt.new is fast because it works in the browser with a limited window of context. That's also why big Bolt projects start to wobble. Once your app is larger than what the agent can hold in view at once, it forgets decisions you made earlier in the chat, builds the same thing three different ways in three different files, and patches one screen in a way that quietly breaks another.
If you've hit that wall, nothing is ruined. The code is fine to work with; it's the agent's view of it that ran out. A developer working in the exported code doesn't have that limit.
Here's what to check before you put a Bolt app in front of paying customers, in the order that matters.
Part 1: Get the code somewhere you control
1. Connected to your own GitHub
While your project lives only inside Bolt, you don't fully control it, and neither can anyone helping you. Connect it to a GitHub repository in your name, and make sure your live site deploys from that repository.
This is also the step that makes everything below possible. Reviewing a codebase in a chat window isn't practical; reviewing it in a repo is routine.
2. You know where it's actually hosted
Bolt projects commonly run on Bolt Cloud or Netlify. Confirm which, confirm the account is yours, and confirm you control the domain. Check whether anything, hosting, database, or domain, is being paid on someone else's card.
Part 2: The database
3. Access rules are on for every table
The single most important check. Whether you're using Bolt's own database or Supabase, your app talks to it from the browser using a public key. That key is meant to be public. The only thing protecting your data is the access rules that restrict each user to their own rows.
How to check: in your database dashboard, look for tables with row-level security disabled. Supabase flags these itself. Any table holding user data without it is readable by anyone who opens your app.
4. The rules aren't quietly permissive
Enabled isn't the same as effective. A rule that permits everything protects nothing, and a read rule with no matching restriction on writes lets people change records they should only be able to view.
How to check: create two test accounts, sign in as each, and confirm neither can see or modify the other's data.
5. Editing a record doesn't duplicate it
A telltale bug in AI-generated apps: saving a change creates a new row instead of updating the existing one, so edits appear to "revert". Check that every record has a stable identifier, that updates target it, and that relationships are enforced by the database rather than only by the interface.
Part 3: Consistency, the Bolt-specific problem
6. One pattern per job
This is what distinguishes a Bolt rescue from any other. Across a large project, the agent will have built the same thing several ways: three approaches to fetching data, two sets of near-identical components, half-finished refactors abandoned mid-way.
It isn't just untidy. It's why fixing one bug creates another somewhere unrelated: a change lands in one of the three implementations and the other two carry on misbehaving.
How to check: search your repository for duplicated component names and for several different ways of calling the same data. If you find them, consolidating is the highest-value work in the whole project, because everything afterwards gets cheaper.
7. Tests on the flows that make you money
Sign-up, login, checkout. Once those are covered by automated tests, you can keep prompting without quietly breaking the things that pay you. Without them, every change is a gamble.
Part 4: Secrets, money, and accounts
8. No private keys in the browser
Database admin keys and payment secret keys must never reach the front end. A database service key in particular bypasses your access rules entirely, which makes every protection above irrelevant.
How to check: open your live app, open the browser's developer tools, and search the loaded JavaScript for service_role, sk_live, and sk-. Rotate anything you find, then move whatever needed it onto the server.
9. Payment access comes from verified webhooks
If your app grants paid access when someone reaches a "payment successful" page, some people will get access without paying and some who paid will get nothing because they closed the tab. Access should come from a Stripe webhook with a verified signature, written so a repeated event doesn't charge or grant twice.
10. The whole account lifecycle works on a phone
Sign-up, email verification, login, password reset, logout, tested on a real phone. Password reset is the one that most often fails quietly.
Part 5: Before launch
11. A real environment setup
A custom domain, a staging environment separate from production with its own database, backups that you have actually restored once, and error monitoring so you hear about crashes before your customers do.
12. It works with realistic data
Prototypes are tested with ten rows. Load a few thousand realistic records into a test copy and use the app. Slow lists usually mean missing database indexes or a query fetching everything and filtering in the browser.
How to read your score
- 11–12: Launch, and watch your error monitor.
- 8–10: Fix the gaps before spending on traffic. Items 3, 4, and 8 always come first.
- Below 8: Don't launch yet. These problems get far more expensive once real customers and real data are involved.
"Bolt says my project is too large"
This message worries people more than it should. It means the project has outgrown what the agent can process at once, not that the code is unusable. It's a signal to change how you work, not to start over.
Two options. Consolidate the duplication so the project is smaller and more consistent, which often brings it back within reach of the agent. Or move to a developer-led workflow, where a human holds the whole system in view and you keep Bolt for smaller, contained changes.
Either way, throwing it away and starting again is the most expensive answer, and rarely the right one.
If you'd rather not do this yourself
Our Bolt app rescue service does exactly this: export and audit, consolidate the duplicated patterns, lock down the data and payments, then finish the build, with one fixed price agreed after the audit and everything in your own accounts.
Built with something else? See the Lovable checklist, or our overview of what breaks in AI-built apps and where.
Push your project to GitHub and send us the link, and we'll tell you what you've actually got.