Part of Vibe code rescue
Your Lovable app, from preview to production.
Lovable writes a React front end on Supabase. The gaps sit where a preview never looks: who can read which rows, which keys reach the browser, what the server checks.
- Under 24 hours for the free written audit
- Every policy read, table by table
- Day one for an exposed service role key
How do you take a Lovable app to production?
Treat the Supabase database as the security boundary, because in a Lovable app it is. The browser talks to Supabase directly, so every table needs row-level security with the right policies, and no service role key in the bundle. Then migrations for the schema and tests for the edge functions.
Who it is for
You need this if
- Users can see each other’s data, or you cannot prove they cannot.
- A service role key in the JavaScript the browser downloads.
- Admin screens hidden in the interface, but open in the database.
- No migration that matches the live schema.
Included
What you get
- Every Supabase policy read, table by table.
- Exposed keys rotated and moved into edge function secrets.
- Permission checks in the database and the edge functions, not only in React.
- The schema under migrations, and a separate staging project.
- Tests on the edge functions that touch money or personal data.
Timeline
How Lovable to production runs
-
Under 24 hours
The audit
We read the repository and the Supabase project, and treat any key ever committed to git as exposed.
-
Days
Close the data
Row-level security on every table with user data, shipped with its policies so the app does not go blank.
-
Weeks
Migrations and tests
Migrations for staging and production, and tests on the edge functions that take money.
-
At handover
Rules for prompting
A pipeline that gates every merge, and rules for what to prompt and what a developer reviews.
Price
What Lovable to production costs
- First step
- A free written audit of the app and its Supabase project, in under 24 hours
- Then
- Stabilisation from $10k; a full rescue $20k to $50k
If rebuilding outside Lovable is cheaper than fixing it, the audit says so first.
Results
Products we have shipped.
“They are honest and they give us ideas about how to improve our entire system.”
Guides
Read before you decide
Questions
Common questions about Lovable to production.
Why a separate page for Lovable?
Lovable apps share one stack and one set of failure modes. Lovable is past 60 million projects, and 4 in 5 of the people building on it are not technical.
Is a Lovable app insecure by default?
Not by design, but its security lives in Supabase policies, where a prompt rarely looks. CVE-2025-48757 recorded the gap: 170 of 1,645 Lovable showcase apps let anyone read user data. Lovable has said apps that handle sensitive data still need outside security experts.
Is the Supabase key in our front end a problem?
The anon key is meant to be public. The service role key skips row-level security, so if it is in the bundle, we rotate it and move it into an edge function secret on day one.
Can we keep building in Lovable after the rescue?
Often, yes: screens, copy and layout stay in Lovable; policies, migrations and edge functions do not. A prompt that undoes a fix fails a check.
Do we have to move off Supabase?
Usually not; it is Postgres and can carry a production app. It needs policies on every table, migrations in the repository and a backup someone has restored once.
One way forward.
Thirty minutes with a builder, not a salesperson, to work out whether we are the right team for it. If we are not, we will say so.