Who can audit an app built with Cursor or Lovable before launch?

Anyone independent who reads the code and the data, not only the screens. I do it as the AI Code Confidence Review, $6,500 fixed for one codebase, with the scope agreed in writing first. AI agents look for problems, a second pass tries to prove each one wrong, and you get the ones that hold up, ranked. It isn't a penetration test, so if the app takes payments or holds health data, a security firm's test is still worth having.

What should I check before launching an app built with AI coding tools?

Start with who can see whose data: log in as two test users and try to open each other's records by changing the ID in the address. Then look for secrets in the code your browser downloads, check that imports keep every row they report, try the app when things fail, such as a declined payment or a dropped upload, and take a database backup you have actually restored once.

Is code written by Cursor or Lovable safe to launch?

It can be, and it usually runs, which is why the problems hide. The serious ones I find are usually about access and data rather than whether a screen works. On a live healthcare platform, a review found a back-end address that handed every client's credentials to anyone with access to a single module, and nobody had reported it.

Writing

What I check in an app built with Cursor or Lovable before it goes live

An app built with an AI coding tool usually works when you click through it. What clicking can't show you is who else can see your data, so that is where I start, and here is the rest of what I check.

Qamar Abbas9 November 20264 min read

AI-assisted, human-edited

On a healthcare platform I reviewed, the app had been live and working, as far as anyone could tell, and the review still turned up two bugs that were broken in production. One was a tab labelled "All" that crashed on any record using one of the newer statuses. The other was a back-end address that handed every client's credentials to anyone with access to a single module, so one client's data was open to the others. Nobody had reported it, because the people who could trigger it weren't looking, and the people who were looking didn't have that access.

I think about that one whenever someone tells me their app was built in a few weekends with Cursor or Lovable and they want to launch it. The tools write code that runs, and a running app is about all you can check by clicking through it. What you can't check by clicking is who else can see your data, so that's where I start.

Who can see whose data

Make two test accounts and log in as each in a different browser. Open a record as the first user, copy the address, and paste it into the second user's browser. If the second user sees the first user's record, the app is hiding things on the screen but not on the server, and it's a problem I find often in AI-written code.

Do the same with anything the app fetches in the background. Open the browser's developer tools, watch the network tab while you use the app, and try one of those requests again with a different ID. If the app keeps its data in Supabase, as many Lovable apps do, check that row-level security is switched on for every table, because a table without it is readable by anyone who has the app's public key.

Secrets in the browser

Anyone can read the JavaScript your browser downloads, so search the app's code for words like "key", "secret" and "token". A payment key, an email provider's key or an AI provider's key in there should be moved to the server and replaced, because once it has been public you can't assume nobody copied it.

Data that goes in quietly wrong

This one doesn't show up as an error at all. On the same healthcare platform, an import had reported success while dropping a third of its data: of 1,796 payer rows, only 1,123 made it in. Fixing it took the live system from 194 to 250 clients. So if your app imports a spreadsheet or syncs from another tool, count the rows going in and the rows that arrived, every time, and have the app say so.

What happens when things fail

AI-written code tends to handle the path where everything works. Try the others: a declined card, an upload that drops halfway, an email address that's already taken, a form submitted twice. If any of those leaves a blank screen or a half-saved record, your customers will run into it before long.

Before the first real user

Take a backup of the database and restore it somewhere once, so you know the backup works. Read any change the tool wants to make to the database before you let it run against live data, because a change that renames or drops a column can't be clicked back. And use the app the way a real person would, with real-looking data, the newer statuses and the edge cases, which is exactly how the "All" tab crash would have been caught.

When to get a second pair of eyes

If the app takes payments, holds personal or health data, or is about to go in front of an investor or a buyer, I'd have someone who didn't build it read the code. That's what my AI Code Confidence Review does: several AI agents read the code at the same time, each hunting one kind of problem, and then a second pass tries to prove each problem wrong, so only the ones that hold up reach you. On an agency portal, 14 parallel checks found 63 problems, the second pass changed the ranking on 11 of them, and the fixes closed 87, older ones included, with 252 of 252 tests passing. It's $6,500 fixed for one codebase, and it isn't a penetration test, so it doesn't replace a security firm when you need one.

On the healthcare platform, the review handled 14 bugs in the end, and 3 of them were held back with the reason written down. That's what I'd expect back from any review of your app, mine or someone else's: the problems that held up, and the ones that were dropped and why. More on the review is on the AI Code Confidence Review page.

Common questions

Who can audit an app built with Cursor or Lovable before launch?: Anyone independent who reads the code and the data, not only the screens. I do it as the AI Code Confidence Review, $6,500 fixed for one codebase, with the scope agreed in writing first. AI agents look for problems, a second pass tries to prove each one wrong, and you get the ones that hold up, ranked. It isn't a penetration test, so if the app takes payments or holds health data, a security firm's test is still worth having.
What should I check before launching an app built with AI coding tools?: Start with who can see whose data: log in as two test users and try to open each other's records by changing the ID in the address. Then look for secrets in the code your browser downloads, check that imports keep every row they report, try the app when things fail, such as a declined payment or a dropped upload, and take a database backup you have actually restored once.
Is code written by Cursor or Lovable safe to launch?: It can be, and it usually runs, which is why the problems hide. The serious ones I find are usually about access and data rather than whether a screen works. On a live healthcare platform, a review found a back-end address that handed every client's credentials to anyone with access to a single module, and nobody had reported it.