We Audited 10 Lovable-Built Apps. Here's What We Found.

AI app builders are genuinely impressive. Describe an app, get a working app. Founders love them, and they should. Getting from idea to demo in an afternoon used to be impossible.

We reviewed ten apps founders built this way and asked one question: would this survive contact with real users? Here is what the audits turned up.

#The pattern: shipped, not safe

Nine of the ten apps ran. They looked done. They had login, dashboards, payments, the works. But "runs" and "safe to put users on" are different bars, and most of them only cleared the first.

The issues clustered into three buckets.

#1. The data was wide open

Six of the ten had an authorization hole. The UI gated things correctly, so a normal user never saw anyone else's data. But the API behind it did not check ownership.

// One real example, lightly anonymized
app.get("/api/orders", async (req, res) => {
  const orders = await db.query("SELECT * FROM orders");
  res.json(orders); // every customer's orders, to anyone who asks
});

Anyone who opened the network tab and replayed the request got the whole table. On two of these apps, that table included email addresses and order history. That is a data breach waiting for one curious user.

#2. Money paths with no guardrails

Four apps took payments. Three of those had a race condition in the fulfillment logic: the success page and the payment webhook both tried to create the order, with nothing stopping both from firing.

Under load, "check if it exists, then create it" is not a safeguard. Two requests can both pass the check before either one writes. The result is a double charge or a double fulfillment, and an angry customer.

The fix is a database constraint, not a longer if statement. None of them had it.

#3. Secrets in the open

Three apps had live API keys sitting in the frontend bundle or committed to git history. One had a payment provider's secret key shipped to the browser. Anyone viewing source could have used it.

The AI did not do this maliciously. It has no concept that one string is a launch code and another is a label. It treats them the same.

#Why this keeps happening

It is not that the tools write bad code. It is that they write code that looks finished. The auth exists, on the frontend. The check exists, without the constraint that makes it real. The validation exists, trusting the client.

That gap, between looks-done and is-correct, is invisible from inside the builder. It only shows up when someone goes looking, or when an attacker does.

#What to do before you launch

You do not need to abandon AI builders. They are a great way to get to a working version fast. You need a review pass before real users and real money show up:

• Test every API call with no session and someone else's IDs.
• Search the repo and git history for secrets.
• Confirm every payment path is idempotent at the database level.
• Add rate limiting to auth and any expensive endpoint.

If you built something with one of these tools and you are about to launch, get it reviewed first. We do exactly this for founders, fast. Send us what you built and we will tell you what we find.