- before
rows=1: ("Patient A","+54 11 4444-0001","allergic to penicillin")afterrows=0control C10 · finding F-06 - before
affected=1; state after = trueafterERROR: permission denied for table profilescontrol C01 · finding F-03 - before
HTTP 200; database writes: POST /rest/v1/payments {"appointment_id":"a1000000-0000-0000-0000-00…afterHTTP 401; database writes: nonecontrol C39 · finding F-04 - before
HTTP 200; stored row: price_cents=1, business_id=attacker-chosen businessafterHTTP 200; stored row: price_cents=500000, business_id=service's businesscontrol C42 · finding F-09
Your AI-built app works. Now make it ready for real customers.
We audit, fix and verify what paying customers depend on: data isolation, auth, payments, staging and backups. Every fix ships with a test that stays in your repo. Fixed scope, fixed price.
- Readiness Review
- $249, credited in full
- Production Graduation
- $1,490, 5–7 business days
- Your code
- You merge every change
- Tenant isolation
- Auth & roles
- Payments & webhooks
- Secrets
- Storage
- Edge functions
- Staging
- Backups
- Regression checks
An audit ends with a list. Ours ends with a passing test.
Every finding becomes a control: a small automated check that tries the attack and confirms normal use still works. Here is one of the 53 from our sample report, from first run to permanent guard.
- 01Before
We reproduce the problem.
Signed in as a different business, an ordinary query returns another company's patient: name, phone and a private note. No hacking tools, only the app's own API.
SQL · signed in as Business BFailselect full_name, phone, notes from public.clients where business_id = '<Business A>';
full_namephonenotesPatient A+54 11 4444-0001allergic to penicillin1 row returnedC10 · Business B cannot read Business A's clients
- 02Fix
We fix it in your code, as a pull request.
One database policy changes. You can read the diff, try it on staging and merge it yourself. Nothing is rewritten for taste.
Pull request · fix(rls): members read clients+3 −3-create policy "read clients" on public.clients - for select to authenticated - using (auth.role() = 'authenticated'); +create policy "members read clients" on public.clients + for select to authenticated + using (public.is_business_member(business_id));
supabase/migrations/0005_security_fixes.sqlYou review · you merge - 03After
Same query, same user, zero rows.
And the business that owns the data still sees it. We test normal use as carefully as the attack, so a fix never quietly breaks the product.
SQL · signed in as Business BPassselect full_name, phone, notes from public.clients where business_id = '<Business A>';
full_namephonenotes0 rows returnedPassNormal use: Business A still reads its own clients1 row - 04Stays protected
The check stays in your repo.
Every pull request runs all the controls. If a future AI-generated change reopens the hole, the check fails before anything is deployed.
CI · tests/run-controls.sh- main · all controls53/53
- New PR · "Add client export" · AI-generated changerunning
- C10 · Business B cannot read Business A's clientsFail
- Merge blocked · nothing reached your customersDeploy stopped
Illustration of a future change. The control and the 53/53 run are real.
Across all controls in the sample report
38 database · 9 edge function · 6 code
As anonymous visitors, outsiders and other businesses
Legitimate users can still do their job
Results from our sample report on turnos-pro, a demo booking app we built to show the method. Not a client. Open the report
Built for the moment real customers arrive.
This is for you if
- You have paying users, or a B2B client or pilot
- The app holds real customer data
- Payments run through the app
- A client or their IT team is asking about security
- Every AI change makes you nervous about breaking production
- There is no staging environment and no backup you have restored
Still just prototyping?
Keep building.
If nobody depends on the app yet, you probably don't need us. Spend the money on the product and come back when the first customer signs.
Also not a fit today: full rebuilds, native mobile apps, backends outside Supabase, and compliance certification work.
Audit, fix, verify, protect.
One fixed scope, agreed before we start. Graduation takes 5–7 business days from access; bigger apps get their own fixed timeline in the proposal.
- Within 48 hours of access
Audit
Read-only review of database rules, auth, edge functions, payments and code. Each finding is reproduced and ranked by what it means for your business.
You get Readiness report + fixed quote - Days 1–5
Fix
Small pull requests against your repo, each explaining what changes and why. You decide what to merge.
You get Pull requests - Days 5–7
Verify
We rerun every control on the fixed code, including the normal-use checks, and send the before and after report.
You get Before / after report - Ongoing
Protect
The controls run in your CI on every change. With Guard, we review each release and keep the checks current as the app grows.
You get Controls in CI
What we check, and what we won't pretend to do.
Covered
- Tenant isolation
- Each user and company only reaches its own rows and files
- Auth & authorization
- Roles, admin flags, team membership, invitations
- Row-level security
- Every policy tested as anonymous, outsider, member and other tenant
- Payments & webhooks
- Signatures, server-side prices, replays, real provider confirmation
- Secrets
- No service_role key, tokens or coupon codes in the browser
- Storage
- Private buckets, folder rules, size and type limits
- Edge functions
- Server-side checks, CORS, error messages
- Business logic
- Double bookings, invalid states, limits your product depends on
- Staging & backups
- A safe place to test, and a restore you have actually run
- Regression checks
- The controls, installed in your repo and CI
Not covered
- Formal penetration testing of live systems
- Compliance certification or audits (HIPAA, SOC 2, ISO 27001, GDPR)
- Load, stress or DDoS testing
- Claims that an app is "100% secure"
- Rewrites to suit our taste
Your app may hold health, financial or other sensitive data, and we will test who can technically reach it. That is not a compliance assessment. If you need HIPAA, SOC 2 or ISO work, we will tell you and you will need a specialist for that part.
Fixed prices, published.
Start with the review. If you continue to Graduation, the review is credited in full.
Readiness Review
A read-only audit with reproduced findings and a fixed quote for the fix.
- Report within 48 hours of access
- Each finding with evidence, reproduction and a fix plan
- Founder summary in plain language
- Fixed-price quote for Graduation
- Credited in full if you continue
Production Graduation
We fix what the review found, prove it with controls and leave those controls in your repo.
- Everything in the Review
- Fixes as pull requests you review and merge
- Staging environment and a tested backup restore
- Controls installed in your CI
- Before and after report
- 5–7 business days
Readiness Guard
Keeps the app production-ready while you keep shipping with AI.
- Review of each release before it ships
- Controls kept current as the app grows
- Reply within one business day
- Cancel any month
Review guarantee
If we find nothing actionable within the agreed scope, we refund the review in full.
Graduation acceptance
50% to start, 50% on accepted delivery. Every deliverable has acceptance controls agreed in writing before work starts. A deliverable is done when its controls pass on your repo, and the second payment is not due until the agreed scope passes.
Payment
USD bank transfer or PayPal. Upwork escrow if you prefer. Prices exclude taxes where they apply.
Larger apps. Multi-tenant B2B, custom auth or more than 30 tables: Graduation Full from $2,900, quoted after the review.
Agencies. Release Gate, our white-label review for client apps: $249 per app, or $790/month for 4 releases. Talk to us
Your code stays yours.
We ask for the least access that gets the job done, work on test data by default and give the access back when we finish. The code and the controls are yours.
-
Read
Read access to the repo and a read-only database role. No production writes.
-
Pull request
Every change arrives as a PR you can read, test on staging and comment on.
-
You merge
Nothing reaches production unless you merge it.
-
Access revoked
We remove our access after delivery and confirm it in writing.
How we handle data
We don't export production customer data. We work from your code, your schema and test accounts, with the least access the job needs.
Read the full data and access policy- Code
- Read access to the repository. Changes only as pull requests.
- Schema
- Policies and functions are tested in a disposable copy, seeded with test data.
- Production customer data
- We don't export it. If something can only be checked in production, we agree it in writing first and use a read-only role.
- Test data
- Synthetic accounts and records we create, like "Patient A" in the sample.
- Secrets
- We never ask for your service_role key or passwords. If we find an exposed secret, we tell you to rotate it and don't use it.
- AI tools
- We use AI tools on your code and schema. If your contracts restrict tools or regions, tell us and we agree the setup before access.
Internal validation benchmark.
Before taking clients, we built practice apps with known flaws and ran the method twice on each, to see what it finds and whether it raises false alarms.
Run by us on our own apps. It is not an independent certification and not a guarantee about your app.
| Practice apps | 2 Lovable-style apps on Supabase, built with known flaws |
|---|---|
| Seeded flaws | 26 · 8 critical, 9 high, 9 medium |
| Deliberate traps | 5 pieces of safe code that look unsafe |
| Critical found | 8 of 8, in both runs |
| High found | 9 of 9, in both runs |
| Medium found | 8 of 9 and 6 of 9, which is why every fix is verified by a control |
| False alarms on traps | 0 |
| Criticals missed by the free scanners we tried | 6, all found by our method |
Read the whole report before you talk to anyone.
The first screen answers the founder's question: can I put customers on this? The rest is for whoever reviews the fix. All 53 controls are included, collapsed until you need them.
turnos-pro is a demo app we built. Sample · not a client.
- 01VerdictReady or not, in one line, with what is still open
- 02Founder summaryWhat blocks launch, what could expose data, whether payments are safe
- 03Next 24 hoursThe exact steps, in order
- 04EvidenceThe real query or request and what came back
- 05ReproductionSteps your developer can rerun
- 06DiffThe fix, as it appears in the pull request
- 07Before / afterThe same control, failing then passing
- 08Positive testProof that normal use still works
- 09Regression controlThe check that stays in your repo
Before you ask.
Anything else: send us your question with the qualifier. We reply within one business day.
Do I have to stop using Lovable?
No. You keep building in Lovable, Bolt, Replit or your editor. We work in your repo and Supabase project, and the controls tell you when a later change breaks something.
Isn't the Lovable or Supabase security scan enough?
Run them, they are a good first pass. Scanners read configuration. We send real requests as different users (a stranger, a customer, a competing company) and check what actually comes back, including payments and business rules a scanner cannot know about. In our internal benchmark, 6 critical flaws were invisible to the free scanners we tried.
Do you fix things, or only find them?
Both. The Review finds, reproduces and ranks. Graduation fixes, verifies each fix with the same control, checks that normal use still works and installs the controls in your CI.
What access do you need?
For the Review: read access to the repo and a read-only database role. For Graduation: permission to open pull requests and access to a staging project. Never your service_role key, never passwords, and no production write access by default.
How do you handle my data?
We don't export production customer data. We test in a disposable copy of your schema with synthetic test data. If something can only be checked in production, we agree it in writing first and use a read-only role. The full policy is on our data and access page.
Is this a penetration test?
No. A pentest attacks a live system from the outside. We review how the app is built and test it in a copy, so nothing touches your users. If a client requires a formal pentest, we will tell you and help you prepare for it.
Do you handle HIPAA, SOC 2 or ISO compliance?
No. We test whether the technical controls work, for example who can read sensitive records. Compliance is a legal and organizational assessment we don't provide. Our sample app stores health notes; we tested who could read them, which is a technical question.
Do you use AI?
Yes. AI agents help us read code, generate and run checks and draft fixes. A person reviews the scope, every reported finding and every change before delivery. More importantly, you don't have to trust either of us: every finding must reproduce, and every fix must pass an explicit control you can run yourself.
Do I have to rewrite my app?
Usually not. Most apps need targeted fixes, not a rewrite. If the review shows a rebuild would really be cheaper, we will say so, and the review fee still counts toward whatever you decide.
What if my stack is different?
We focus on apps backed by Supabase (Postgres, Auth, Storage, Edge Functions) with a React, Vite or Next.js front end. Native mobile apps and other backends are not supported today; the qualifier will tell you in a minute.
What happens after Graduation?
You keep the controls and run them on every change. If you want us to keep watching, Readiness Guard reviews each release before it ships for $290 a month, cancel any month.
Who will I work with?
A small specialist team. You talk directly to the person doing the work. If you want to meet before paying, we do a private video call.
Check if your app qualifies.
Answer five quick questions and see right away whether Graduation fits, or whether to start with the review. If it fits, send your details and we reply within one business day.
- No passwords, keys or access needed at this step
- We never scan or review an app without its owner's request
- Prefer email? hello@prodmettle.com