Built with Lovable
Lovable does the build. Some of it stays yours.
Their documentation is clear about which parts. It arrives as documentation, though, and nobody reads documentation while shipping.
Everything below is quoted from Lovable and linked to the page it comes from. Nothing here says the platform is unsafe; it says which half of the job has your name on it.
Lovable is a trademark of its owner. This page quotes their public documentation to explain a scope of work. There is no partnership, endorsement or affiliation in either direction.
What stays yours
Where the platform stops.
Lovable builds the tables, wires the auth pages and deploys the result. These are the parts it hands back to you.
The row-level rules on every table
Lovable creates the tables from your description. Deciding who may read and write each row is left to you, and their guidance is direct about it: “Before going live, make sure every table has Row Level Security policies that restrict who can read and write each row.” They also ask you to verify the policies yourself in the Supabase dashboard.
The migrations you approved
Database changes arrive as migrations for you to review before they run. Approving one is a decision about your data, taken at the speed of a chat message — and a table created without policies is created exactly this way.
The route a secret takes
There is a safe path, and Lovable documents it: keys go into Secrets, an edge function uses them server-side, and the browser calls that function. A key that instead lands in frontend code has skipped that path — and whatever the browser downloads, every visitor downloads.
The authentication settings
Lovable wires the sign-up and sign-in pages, and users appear in your Supabase project. The settings that govern how that auth behaves are configured in the Supabase dashboard rather than through Lovable, which means nobody configures them unless you do.
Lovable says the same thing about its own tooling: their checks “do not replace a thorough security review”, and for an app handling anything sensitive they recommend getting one.
Check it tonight
Where to look, right now.
Free, and none of it needs me. Each check maps to one of the parts above.
Look at what your published app downloads
Open your live Lovable URL, view the page source, and search it for sk_live, service_role and secret. The browser can only run what it downloads, so anything you find there is public.
Read the RLS column in Supabase
Open your project, go to the table editor, and look at every table. Lovable asks you to verify this yourself, and it is a two-minute read: a table with no policies answers to anyone holding the public key.
Open one of your own records logged out
Copy the address of a record you own, then open it in a private window. If it loads without a session, the rule protecting it lives in the interface rather than in the database.
Scroll back through the migrations you approved
In the Supabase dashboard, read the migration history. You are looking for tables created without a matching policy — the gap opens at the moment of creation, not later.
Any of these failing is your answer, free. To hand the whole job to your own AI tool instead, the five-flaw prompt covers the same ground and more.
What a read adds
Checks find the obvious ones.
The four above catch a published key and a table with no policy. They cannot tell you that a policy exists but lets any signed-in user read every row, or that the edge function trusts an id the browser sent it.
Those need someone reading the code, which is the audit. What I check is published, including where the scope stops.
€350 + VAT · 48 hours
An independent pass over your app.
Your repository and your live app, every finding with the evidence, what it costs you and a prompt you can paste back into Lovable.
€430.50 including VAT.
Start here
Not sure it is worth it?
Send me the five questions. If a Lovable app this size does not need the audit, I would rather tell you that than take the money.