The report
Every finding with a severity, where it is, what it exposes and how to fix it. Written for a founder to read and an engineer to act on.
01 · 1 week
Production Audit
The whole codebase and the database behind it, read by a senior engineer against the checklist on this site. Five days later you have a report you can act on, with a fixed quote for the fixes attached. $1.5K fixed.
Price
$1.5K
Included
Access control, secrets, data, deploy
Included
Every finding with a severity and a fix
Included
A quoted price for the hardening
Report in handD5
Fixed$1.5K
Every tableRLS
Open criticals0
How it works
You give read access to the repository, the database project and the hosting account. The audit works through the published list: row-level security on every table, secrets in the bundle or in git history, whether preview and production share a database, where the backups actually live, what happens on the first request after deploy, which screens fetch every row, which errors are logged where nobody reads them, and whether a single test exists.
Every finding goes into a written report with a severity, the exact file or table, what it would let a user do, and the fix. The report ends with a quoted price and a date for the Production Hardening, sitting inside its published band. You can take that quote, hand the report to someone else, or fix it yourself. It is written so all three work.
This is not a scanner. Lovable's own publish check lints RLS and says in its documentation that it cannot guarantee security; it does not see a view that bypasses the policies, a service key in a client fetch, or a backup that lives in the volume it protects. Those are the findings that cost people their launch.
What you get
Four things land on your side.
The critical fixes, done
Anything that lets an anonymous user read or write another user's data is fixed during the audit, not after. You do not wait a week with that open.
A quoted price and a date
The hardening, priced inside $5K–$15K and dated in writing. The audit fee comes off that price if you go ahead.
A thirty-minute walkthrough
The findings on a call, in severity order, with the question of what to fix first answered plainly.
How it runs
Production Audit, week by week.
Access
Day 0: read access to the repo, the database and the hosting account. The fee is invoiced.
Read
Days 1–3: the checklist, item by item, against the real code and the real database. Critical access-control holes are closed as they are found.
Report
Day 5: the written report and the hardening quote, then a thirty-minute walkthrough.
Decide
Take the quote, fix it yourself from the report, or hand the report to whoever you like.
Questions
What people ask before they book.
- Which tools do you audit apps from?
- Lovable, Bolt, v0, Replit, Cursor, Claude Code, Windsurf, or anything else that produced a React or Next.js app with a Supabase, Firebase or Postgres backend. The checklist is about the app and the database, not the tool.
- Why not just run Lovable's security scan?
- Run it. It catches tables with no RLS at all, and it is free. It does not read your policies for logic errors, it does not know a service-role key is in a client fetch, it does not look at your hosting account or your backups, and its documentation says plainly that it cannot guarantee security. The audit is the part a scanner cannot do.
- What do you need from me?
- Read access to the GitHub repository, the Supabase or database project, and the Vercel, Netlify or hosting account. Two sentences about who the users are and what they pay for. Nothing else.
- What if the report says the app should be rebuilt?
- Then it says so, with the reasons, and the quote is for a Build instead. That happens less often than people fear. Most vibe-coded apps are a sound idea with a thin backend, and the backend is what gets fixed.
Start here