Built with Lovable, Bolt, v0 or Cursor? I find the database rules that let one customer see another customer’s data — and fix them. Fixed price. Written report. Everything by email.
How it happens
Step 1 of 3
In a multi-company app, every customer’s rows live in the same tables. Database rules (RLS) decide who can see which rows.
Step 2 of 3
Nothing looks broken. But one customer’s screen can now read, or change, another customer’s data.
Step 3 of 3
The tests sign in as real users and try to cross the line. Every one has to fail to get through.
Services
Lovable · Bolt · v0 · Cursor — on Supabase
Apps built fast with AI often ship with database rules that look fine but are not. The most common one: a customer can see or change another customer’s data.
You get a written report for founders first, developers second.
from $150 — fixes from $350
Case study
I took a CRM built with Lovable on Supabase and reviewed it exactly as I would a client’s app before launch. The repo is agency-client-hub.
This is a demo project, not a client. It is my proof of how I work.
Prices
| What you get | Price |
|---|---|
| Audit + written report | $150 |
| Audit + fixes for critical and high issues, each checked with a test | $350 |
| Full hardening: every issue fixed, automated isolation tests, documentation | $700 |
Bigger apps: I quote a fixed price after reading the code.
I’m Luca, a Tech Lead working with Next.js, TypeScript, React, Supabase, PostgreSQL and Vercel. I also build with AI tools such as Claude Code and MCP servers.
AI-built apps on Supabase tend to repeat the same database mistakes. They are easy to fix once someone looks carefully, and that is the work I do.
I am not a certified penetration tester. What I offer is careful, reproducible checks, with evidence you can rerun yourself.
This studio is my own independent work.
FAQ
Row Level Security (RLS) is the set of database rules in Supabase that decides which rows each signed-in user can read or change. When many customers share the same tables, one missing or loose rule can let one customer see or change another customer’s data. Nothing looks broken when that happens, so it takes a careful look to find it.
No. I only test with your written permission, on a local copy built from your code and migrations, with test accounts. I never touch your users’ real data, and I never test a live system without your permission.
Access to the code, including the Supabase migrations (a GitHub repository is easiest), a few lines on who your users are and what each role should be able to do, and your written permission. Everything happens by email.
For a typical app, the report arrives within 5 working days of getting access to the code. Fixes add 3–5 working days. For bigger apps, I confirm the date in writing before I start.
A written report for founders first, developers second: each finding with its severity, what it means for your business and the evidence to reproduce it. With the fix packages you also get the fixes as a database migration, each one checked with a test you can rerun.
Then the report says so, and shows what I checked and how, with tests you can rerun yourself. It is careful, reproducible work, not a guarantee that nothing else can go wrong: I am not a certified penetration tester.
Also, for B&Bs and small hotels in Italy
A chat widget that answers your guests’ questions day and night: check-in, parking, breakfast, directions and house rules. In Italian, English, German, French and more.
Try a free preview with your own information before you decide.
€390 one-time, first property
Each additional property + €100–150. You pay your own AI usage directly, usually a few euros a month.
Write to me about a guest assistant →
In italiano: [email protected]
Contact
I reply by email, usually within a couple of working days.
If I notice a serious problem in public code, I tell the owner privately and for free. That is separate from any offer.
Thanks. I reply by email, usually within a couple of working days.