Was your app built with Lovable or Bolt? The 6 problems we find most often in production

An app built with AI has a huge advantage: it reaches production in days, not months. And it has a disadvantage that only shows up later: nobody looked at it as a whole. The tool generated it screen by screen, prompt by prompt — and every prompt worked.

When we audit apps built with Lovable, Bolt, Cursor or v0, the problems are rarely in what you can see. They are in the connections between the parts. These are the six we find most often.

1. One customer's data visible to another

In apps with several companies or accounts, each customer should only see their own data. When the database is Supabase, that separation lives in the access rules (RLS). The AI creates tables quickly — and the rules end up missing, too permissive, or trusting a value the user sends themselves.

On a financial platform we fixed, we closed 16 of these leaks before the first real customer.

2. Users who promote themselves to admin

The AI generates endpoints that update "the user's profile". If the endpoint accepts any field, a regular user can change their own role to administrator.

3. A database open to the world

The public Supabase or Firebase key is meant to live in the browser. It is only safe because access rules decide what each request can read. Without rules — or with "allow everything" rules added to "unblock" an error during development — anyone with the key can read, change or delete the data in every exposed table.

4. Errors pretending to be "no data"

A very common pattern: a request fails, but the app shows "you don't have any records yet". The user thinks there is nothing, the founder thinks nobody uses the feature — and the error goes unnoticed for months.

5. Slowness that only appears with real customers

With ten records, everything is fast. With ten thousand, queries without indexes and logic that runs row by row make the app slow — and in Supabase, badly written access rules weigh on every query. In a recent audit we found dozens of foreign keys without an index.

6. No tests and no CI pipeline

The AI fixes what you ask it to, but it doesn't know what will break elsewhere. Without automated tests, every fix is a gamble — and the same problem comes back two weeks later.

What to do if you recognise your app here

None of these problems means throwing the app away. The order we follow is always the same:

Know what is at risk — an audit of the code, the architecture and the access rules, with findings by severity.
Fix the critical issues first — data leaks and permissions before anything else.
Make sure it doesn't come back — tests for the access rules and a pipeline that runs them on every change.

Building with AI is a real advantage. Putting it into production without anyone looking at the whole is where that advantage is lost.

If your app was built with AI and already has users, talk to us — in 30 minutes we'll tell you whether it really needs an audit.