Lovable ships features fast. The same pattern that makes that possible — confident code, idiomatic-looking output, fast iteration — is what hides the risk we read for. We audit Lovable codebases line by line, name what's broken, and tell you what to fix first.
Full-stack web apps generated end-to-end (UI + backend + Supabase) from a single prompt, then iterated on through chat.
The database has tables marked as public, or RLS policies of the form `USING (true)`. Anyone with the project's anon key — which is meant to be public — can read or write the full table from a browser. The application looks safe because the UI gates the views, but the data is open by default.
A privileged key (typically Supabase service_role, Firebase admin or a payments secret key) ends up referenced in client-side code. The build pipeline inlines it into the JavaScript bundle, where any visitor can read it from DevTools and bypass every row-level rule the database has.
Endpoints that mutate data — create, update, delete — accept requests without ever checking for a session, JWT or API token. The UI hides the buttons behind a login screen, so the developer assumes the API is protected. It isn't: anyone with curl and the URL can call it.
A query reads by id but never checks that the id belongs to the authenticated user — typically `SELECT * FROM invoices WHERE id = ?` instead of `... WHERE id = ? AND user_id = ?`. Two seeded test accounts can read each other's records by changing a number in the URL.
Any authenticated user can hit the LLM endpoint as fast as their browser will send requests. A loop in DevTools — or a single curious user finding the right textarea — burns through the monthly inference budget in an afternoon.
Knowing the tool that built the code lets us focus the audit. We start by detecting the Lovable signature in the codebase, then we read the surfaces where Lovable-specific failure modes cluster: auth, secrets, data access, dependencies and LLM-touching paths. Five to ten business days from kickoff to written report. No deployment access required — read-only repository access is enough.
Severity-ordered findings with file paths, line references, why it matters and a fix sketch. Readable by both engineering and non-technical stakeholders.
15-minute recording of the report — for the cofounder, investor or director who didn't make the live call.
Live discussion of severity, fix order and the calls that need a human in the loop.
Slack or email for clarifications, fix reviews and a second pair of eyes on the patches.
Typical SMB AI-built codebase, kickoff to written report. Larger or multi-repo audits scoped separately.
Often yes. Auth bolted onto routes that were already public is one of the most common Lovable findings — the prompt added a login screen but didn't lock down the API endpoints behind it.
RLS policies (most common: USING (true) left over from generation), public storage buckets, service_role keys in the client, and whether the schema has per-user isolation that actually enforces in queries.
‘Production-ready’ in a builder context means ‘deployable’, not ‘safe under real users’. The audit finds the gap between those two, with the failure modes specific to Lovable-generated apps.
Next.js, Python and full-stack apps with Tailwind, shipped at high velocity by individual developers.
Read more →Terminal-driven, multi-file changes across a codebase — often touching infra, tests and product code in a single agent loop.
Read more →Inline completions across enterprise codebases, mixed with hand-written code from many authors over years.
Read more →We design for privacy from the start, human control, traceability, usage limits, permissioning and documentation. For sensitive processes, we help assess risk and applicable obligations under GDPR and the EU AI Act.
Every engagement is led personally by one of the partners. If there's a fit, you get a personal first read of your case within one business day — not a canned demo.
