AI App Builder Audits · AI Development Series
Lovable App Audit
You built it with Lovable and it works. Before you put real customers and real data through it, it is worth knowing what is underneath.
What Lovable actually hands you
This matters because it determines what an audit is even looking at. Lovable is not a black box — it generates real code, and you can export the whole thing to GitHub and open it in any editor. That is genuinely to its credit, and it is also why a proper review is possible at all.
The stack Lovable generates
- Frontend React with TypeScript, built with Vite, styled with Tailwind and shadcn/ui components
- Database PostgreSQL, hosted on Supabase
- Authentication Supabase Auth
- Server logic Supabase Edge Functions, running on Deno
- Files Supabase Storage
- Access control Postgres row level security policies
Note what is not in that list: there is no separate backend server sitting between your users and your database. The React application in the browser talks to Supabase more or less directly, using a public API key that anyone can read out of the page source. That is a completely legitimate architecture — Supabase is designed for it — but it moves the entire security burden onto one thing: your row level security policies.
If those policies are right, the design is sound. If they are wrong, missing, or written permissively to make something work during the build, then every record in your database is one browser console away from anybody who signs up. This single fact explains most of what we find in Lovable applications.
What we consistently find
These are not hypothetical. They are the issues that come up again and again in the Lovable and Supabase applications people bring us, described in the order we tend to hit them.
Row level security that is off, or on but permissive
The most common and the most serious. Supabase will happily let you create a table with row level security disabled, and a generated app will work perfectly that way — right up until it has a second user. We also see the subtler version: policies that exist, so the dashboard shows a reassuring green tick, but which are written to allow any authenticated user to read any row rather than only their own.
The reason this survives testing is that it is invisible when you are the only person using the application. You log in, you see your data, everything looks correct. It only becomes apparent when two separate customers are in the system and one of them goes looking.
What it costs you: this is a personal data breach under UK GDPR, reportable to the ICO within 72 hours of becoming aware of it.Permission checks written in React instead of in the database
Generated code frequently hides a button, or filters a list, based on the logged-in user's role — and stops there. The interface behaves correctly, so it passes every test a non-developer would think to run.
But that check lives in JavaScript that runs on the user's own machine. Anyone can open developer tools and call the underlying query directly with the public key. If the database is not independently enforcing the same rule, hiding the button protected nothing at all. Interface logic is a convenience for honest users; it is not a security control.
What it costs you: privilege escalation. Ordinary users reaching admin data and admin actions.A database schema that does not match the business
Generated schemas tend to be shaped like the screens that were described, not like the domain underneath them. One application we looked at recently arrived with a single table where the work it was doing genuinely needed something closer to forty. Every figure the system displayed was being recalculated from scratch on each page load, because there was nowhere to put an intermediate result.
It ran fine in the demo. With a few hundred records it was slow. With a few thousand it would not have loaded at all. And because everything was crammed into one place, there was no way to fix the performance without redesigning the data model — which meant redesigning the parts of the application built on top of it.
What it costs you: the rebuild you were trying to avoid, arriving later and costing more.Edge Functions holding the key that bypasses everything
Supabase issues a service role key that ignores row level security entirely, by design, so that trusted server-side code can do administrative work. Generated Edge Functions often reach for it because it makes the function work first time.
The risk is what that function then accepts. If it takes an identifier from the request and trusts it, you have built an endpoint that will return or modify anybody's data on request, no matter how carefully the rest of your policies are written. We check every function that holds this key and what it is prepared to do on a stranger's say-so.
What it costs you: a single unchecked function undoes your entire access control model.No indexes, and queries that will not survive growth
Postgres does not add indexes on foreign keys for you, and generated schemas rarely add them either. On a table with a hundred rows this is unmeasurable. On a table with a hundred thousand it is the difference between a page that loads and a page that times out.
Alongside this we usually find the classic pattern of fetching a list and then making a separate database round trip for each item in it — fine at ten items, ruinous at a thousand. Both are straightforward to fix once identified. Neither is visible until you have real volume.
What it costs you: the application gets slower as you get more successful.Nothing that tells you when it breaks
Generated applications almost never arrive with automated tests, error tracking, or a way of knowing that something failed for a customer at two in the morning. The first report of a problem is usually the customer.
This is less dramatic than a data breach but it is the one that quietly costs the most, because it means every change you make afterwards is a gamble. You cannot safely modify software when you have no way of telling whether you have broken it.
What it costs you: every future change is slower and riskier than it should be.Where Lovable is genuinely good
None of the above means you were wrong to use it. Lovable is very good at something that used to be expensive and slow, and the fact that it produces real, exportable code puts it well ahead of the platforms that trap you in a proprietary format.
Genuinely well suited to
- Getting a working prototype in front of people in days rather than months
- Proving an idea before committing a development budget to it
- Internal tools used by one person or a small trusted team
- Showing investors or stakeholders something real instead of a slide deck
- Establishing what the product should actually do before it is built properly
Where it needs engineering behind it
- Multiple separate customers whose data must never mix
- Anything holding personal data, health data, or payment details
- Applications that need to keep working as volume grows
- Anything your business would genuinely suffer without
- Software you intend to keep changing for years
The honest summary: Lovable is excellent at the first eighty per cent and leaves you on your own for the last twenty, which is the part that determines whether the thing survives contact with real users. Knowing which side of that line your application currently sits on is the entire point of an audit.
Nobody who brings us a Lovable app has done anything wrong. They had an idea, they built it, and it worked — which is more than most people manage. The problem is that the tool is confident about things it has no way of knowing, like who is allowed to see what. That is the bit we check.
Prefer to watch? The short version of who we are and how we work
Do you need an audit?
Get it looked at if
- More than one customer or organisation uses it
- It stores personal data of any kind
- It takes payments or sits near anything that does
- You are about to promote it, launch it, or raise on it
- You have stopped being able to change it confidently
You are probably fine if
- You are the only person who uses it
- It holds nothing you would mind losing or leaking
- It is still a prototype and everyone treats it as one
- It is a throwaway you will rewrite when the idea is proven
Questions about auditing a Lovable app
No. We need the code, which you can export to a GitHub repository from Lovable and share with us, and ideally read-only access to the Supabase project so we can inspect the database schema and the row level security policies. We do not need to log into Lovable itself, and we will not change anything in your application.
Usually not, and we have no incentive to. A Lovable application that has a sensible data model and a couple of security gaps is worth fixing, and fixing it is cheaper than rebuilding it. The cases where we recommend starting over are the ones where the database design cannot support what the business actually needs — and in those cases we will show you why rather than asking you to take it on trust. The report says what we found, including the parts that are fine.
For some things, yes, and where that is the sensible route the report will say so. The difficulty is that you have to know precisely what to ask for. Asking a generator to "make it secure" tends to produce code that looks more secure without necessarily being so, and you have no independent way of checking. The audit exists to tell you exactly what is wrong and in what order it matters, which is the part that is hard to get from the tool that wrote it.
No, and we would rather say so plainly than pretend otherwise. We build with Claude Code and Cursor, with senior developers designing the system, reviewing every change and testing it. What makes us useful here is not Lovable expertise, it is that Lovable produces React, TypeScript and PostgreSQL — which is what we have been building and fixing for years.
You get the written report within five working days of us having access to the code. Most Lovable applications are small enough that we are quicker than that. If we find something serious enough that you need to act on it immediately, we tell you as soon as we see it rather than waiting for the report.
Built with something else?
We audit what these tools produce, whichever one you used.
Other AI app builders
- Emergent app audit
- Replit app audit
- UI Bakery app audit
- Bolt app audit
- v0 app audit
- Base44 app audit
- Firebase Studio app audit
- Databutton app audit
- Rork app audit
- a0.dev app audit
- FlutterFlow app audit
- Bubble app audit
- Glide app audit
- Softr app audit
- Adalo app audit
- Retool app audit
- Appsmith app audit
- Budibase app audit
- ToolJet app audit
- Xano app audit
- Airtable app audit
The audit
Find out what you are sitting on
The AI Code Audit is £495, fixed.
Tell us roughly what the application does and how many people use it. If an audit is not the right thing for you, we will say so.
What the report covers:
- Security and access control, including your row level security policies
- Database structure and whether it fits the business
- Whether it will hold up as usage grows
- Whether it can be maintained and changed safely
We reply within one working day.
