Built your app with Lovable, Bolt or Cursor? What to check before customers arrive

If you built your app with Lovable, Bolt, Replit or Cursor, it probably works. The question before launch is whether it's safe, and the answer depends on parts you can't see on the screen.

The same seven problems turn up in almost every AI-built app we review. You can check most of them yourself in an afternoon.

Seven problems, and how to spot them

Problem	How to check it yourself	The fix
Permission checks only on the screen	Log in as user A, change an ID in the URL or request, see if user B's data loads	Check ownership on the server for every request
Secrets in the code	Search the code for "key", "secret" and "password"	Move them to environment settings and rotate the keys
Database rules wide open	Look for rules that allow every read and write	Lock rules to the signed-in user and their own records
Outdated or invented packages	Run your package manager's audit, look up any name you don't recognise	Update, replace, or remove what doesn't exist
Inputs taken on trust	Paste a long string or some HTML into every form	Validate on the server and escape what's shown back
No tests	Ask: what tells you a change broke sign-in?	Tests around sign-in, payments and the main flows
No error tracking	Ask: how would you know it failed for a customer last night?	Error tracking and an alert before launch

The first row is the one that worries us most. The app looks fine, the screen hides other people's data, and the API hands it over to anyone who asks.

Why do AI tools miss these?

Because they build what you ask for and what you can see. You ask for a dashboard and you get a dashboard. You never asked "and check this user owns this invoice on the server", so often it isn't there.

It's a pattern across the industry. Veracode tested AI-generated code from many models and found 45% of the samples failed its security tests. AI tools sometimes also suggest packages that don't exist, which attackers can register under that name.

Fix or rebuild?

Fix, most of the time. An AI-built app usually has a reasonable structure and a short list of serious holes. A rebuild throws away everything that works and costs months.

We suggest a rebuild only when the review shows something structural, like a data model that can't hold what the business needs. When that happens, we explain it in the review in plain words.

What a rescue looks like with us

1. Review, about a week. We read the code, run it and write down what we find, ranked by what could hurt you first. You keep the review either way, with a fixed quote for the fixes.
2. Security fixes first. Permission checks, secrets and database rules, starting with anything open to the internet.
3. Tests around what matters. Sign-in, payments and the main flows, so the next change, by a person or an AI tool, can't break them quietly.
4. Launch with monitoring. Error tracking on, so you hear about problems before your customers tell you.

You can keep building with AI tools afterwards. We leave instructions in the repo that tell the AI how your app handles permissions and secrets, plus tests that every change has to pass.

Before you launch

Do the first three checks in the table today. If any of them turns something up, don't launch yet.

When AI builds software for people who can't read the code, the checks have to live somewhere solid. We learned that leading engineering on an AI platform where non-coders build businesses. Our app rescue and modernisation work applies the same thinking to your app, and if your app has AI features of its own, AI security testing covers those too. Or tell us what you built and what it's built on.