Row Level Security left permissive
Lovable wires Supabase quickly, and the fastest path leaves RLS policies open or disabled. Any user with your anon key can often read tables they should never see. This is the first thing we close.
Lovable → production
You got it to roughly 90% — the idea is visible and it runs. We review what you built in Lovable, write the missing 10%, and put it live in front of real users. Usually within a week.
You get back the three biggest things standing between your Lovable build and real users, in writing, within two business days. No call needed. If you want the full version, the fixed-price review is €750 — fixed price, credited back if you continue.
Not a criticism of the tool — Lovable got you further in a weekend than a contractor would in a month. These are just the things it consistently leaves for a human, and they are the things that decide whether your launch holds.
Lovable wires Supabase quickly, and the fastest path leaves RLS policies open or disabled. Any user with your anon key can often read tables they should never see. This is the first thing we close.
Sign-in works. Email verification, password reset, session expiry, and account deletion usually do not. Those are the ones your first real users will hit.
Forms check themselves in the browser, and the database trusts whatever arrives. We add server-side validation and constraints so bad data cannot land.
A Stripe checkout button is not billing. Webhooks, failed payments, refunds, and subscription state need to actually match your database.
The offer
Start with the review: we read your Lovable build route by route and hand you a written plan with effort and risk on every item. If you continue, the review fee comes off the build. Prices in EUR, excluding VAT. USD invoicing available.
Yes. Lovable pushes to a GitHub repo you own — a standard Vite/React project against a Supabase instance. It deploys to Vercel, Netlify, Cloudflare or a container host like any other React app. The work is not the deploy; it is the Supabase policies, the environment split, and the secrets that were fine while only you were using it.
Take the anon key out of your own app, and query a table you should not be able to read — from curl, signed out. If rows come back, RLS is off or the policy is permissive. Do this for every table, not just the obvious ones; the default setup usually leaves several open.
Not until RLS is enforced per table, validation exists server-side, and you have backups you have actually restored once. Those three are the minimum. We check all of them in the free teardown.
Question not here? Email me — I answer these myself, and I do not need you on a call first.
Different tool again, or a mix of several? Tell us what you used — the process is the same.