If you built your app with Lovable, Bolt, Cursor, Replit or a similar tool, the parts that usually need fixing before launch are the ones a demo never exercises: who can see which data, where your secret keys live, what happens when something fails, and whether you can recover when it does. Below are the ten fixes we check first on AI-built apps, how to spot each problem yourself, and what the fix involves.
Key takeaways
- Test with two accounts. The most serious launch bugs are users seeing or changing each other’s data.
- Anything in your frontend is public. Keys bundled into the browser can be read by anyone.
- Database rules are not optional. On Supabase, every exposed table needs Row Level Security and real policies.
- Plan for failure. Error handling, backups you have restored at least once, and alerts that reach a person.
Why an app that works can still be unready
AI builders are optimised to produce something that works when you click through it. That is genuinely useful: you can validate an idea in days instead of months. But a demo has one user, a fresh database, no attackers, and no bad days. Launch changes all four at once. Real users sign up on old phones, mistype email addresses, open two tabs, and occasionally poke at your API to see what it returns.
None of this means AI-generated code is bad. It means nobody has yet asked it the awkward questions. The checklist below asks them. It is ordered roughly by risk, so if you only have a day, start at the top.
The 10 things to fix before launch
1. Make every authentication flow work for a stranger
Demos are usually recorded by someone who is already logged in. Open your app in a private window on a device that has never seen it and go through the full lifecycle: sign up, confirm the email, sign out, sign back in, reset the password, and change the email address. Then try the unhappy paths: a wrong password five times in a row, an expired reset link, and a confirmation email opened on a different device.
Common findings are confirmation emails that never arrive because the email provider is still in test mode, password reset links pointing at the preview domain instead of your real one, and login endpoints with no rate limiting. Fixing these is rarely hard. Finding them before your first hundred users do is the point.
2. Check that users can only reach their own data
Broken access control is first on the OWASP Top 10:2025 list for a reason. The classic version in an AI-built app: the page only shows your own invoices, but the API behind it will happily return anyone’s invoice if you change the ID in the request.
The test is simple. Create two accounts. As user A, create a record and note its ID or URL. Sign in as user B and try to open, edit and delete it, both through the interface and by replaying the request in your browser’s developer tools. If anything works that should not, fix it on the server or in the database, never only in the interface. Hiding a button does not protect the data behind it.
3. Move secrets out of the frontend
Anything compiled into your JavaScript bundle can be read by anyone who opens your site. Build tools make this easy to do by accident. In Vite, every variable prefixed with VITE_ is inlined into client code, and the Vite documentation warns that these should not hold sensitive information. Next.js does the same with NEXT_PUBLIC_ variables.
Search your built files for strings like sk_, secret, service_role and Bearer. Payment provider secret keys, AI provider API keys and database admin keys belong on the server, in a backend route or serverless function. If a secret was ever exposed, moving it is not enough: rotate it, because copies may already exist. Enabling GitHub push protection helps stop the next one reaching your repository.
4. Turn on database access rules and test them
Many AI builders pair a frontend with Supabase or Firebase, where the browser talks to the database directly. That model is safe only if the database enforces who can do what. Supabase’s Row Level Security documentation is explicit: a table in an exposed schema without RLS can be read and written by any role that has a grant on it. The publishable (anon) key in your frontend is not a secret, so RLS is what stands between it and your data.
Check that RLS is enabled on every table, that each table has policies for select, insert, update and delete that match your intent, and that the service role key, which bypasses RLS entirely, never appears in client code. Then repeat the two-account test from fix 2. Policies that look right can still be wrong.
5. Validate input on the server
Form validation in the browser is for user experience; it is not security. Anyone can send your API a request that skips the form. Every endpoint should check that required fields exist, that types and lengths are sane, that IDs belong to the current user, and that uploaded files are the type and size you expect. Libraries such as Zod make this straightforward if your app is written in TypeScript, and many AI-generated codebases already include them on the frontend, ready to reuse on the server.
6. Handle errors without leaking or failing open
OWASP added a new category in 2025, Mishandling of Exceptional Conditions, which covers exactly what generated code tends to skip: what happens when a call fails. Look for three things. First, users should never see raw stack traces or database errors, which reveal how your system works. Second, failures should fail closed: if the permission check errors, the answer is no. Third, the user should get a clear message and a way forward, not a blank screen.
7. Review dependencies and lock them down
AI tools install packages freely, sometimes outdated ones and occasionally ones that do not exist, which attackers can register under the hallucinated name. Software supply chain failures are now third on the OWASP list. Commit your lockfile, run npm audit (or your ecosystem’s equivalent), remove packages you do not use, and turn on automated dependency alerts so you hear about new vulnerabilities after launch.
8. Add tests for the flows that make you money
You do not need full test coverage to launch. You do need confidence that the next change will not silently break sign-up, the core action your users pay for, or checkout. Three to five end-to-end tests covering those flows, running automatically before each deploy, will catch most regressions. Without them, every AI-assisted edit is a gamble on code that nobody has read in full.
9. Set up backups, then prove you can restore
Check what your database provider actually backs up, how often, and for how long. Then do a restore into a separate project. Teams discover alarming things this way: backups that are not enabled on their plan, restores that take hours, or point-in-time recovery that would have needed a setting turned on weeks earlier. PostgreSQL supports point-in-time recovery, and most managed providers expose it, but only a tested restore tells you it works for you.
10. Make sure someone finds out when things break
After launch, you should hear about errors before your users email you. At minimum, add error tracking for the frontend and backend, uptime monitoring on your main URL and API, and logs you can search. Keep secrets, passwords and unnecessary personal data out of those logs. Then route alerts to a person who will read them, not an inbox nobody checks.
If you cannot do everything this week
Not every fix carries the same risk. If you have to launch on a deadline, this is how we would order the work:
| Fix | Risk if skipped | Typical effort |
|---|---|---|
| Authorisation and database rules (2, 4) | Data leak between users | Hours to days |
| Secrets in the frontend (3) | Account takeover, surprise bills | Hours, plus key rotation |
| Authentication flows (1) | Users locked out, support load | Hours |
| Backups and restore (9) | Permanent data loss | Hours |
| Error handling and monitoring (6, 10) | Silent failures | A day or two |
| Validation, dependencies, tests (5, 7, 8) | Bugs and slower future changes | Days, then ongoing |
A one-hour self-check you can run today
- Open the live site in a private window and complete sign-up, sign-out, sign-in and password reset.
- Create two accounts and try to open each other’s records by changing IDs in the URL.
- View the page source and the JavaScript files, and search them for keys and secrets.
- If you use Supabase, open the table editor and confirm RLS is enabled on every table.
- Find your backup settings and write down the restore point you would use today.
- Trigger an error on purpose and check what the user sees and whether anyone is alerted.
If two or more of these surprise you, that is normal, and it is much cheaper to fix now than after launch. Many of these issues only appear outside the builder’s preview, which we cover in why AI-built apps work in development but break in production. For a deeper security pass, see our AI-generated code security checklist.