Know which of your access rules hold before an investor, buyer or customer asks.

Your schema and policies are loaded into a throwaway local database. We never touch your live one. We then test a written list of claims, agreed with you at the start. Each is tried with made-up users, organisations and rows, signed in and signed out. The secrets check is a scan of your source code rather than a live test.

1. Check 1

   Tenant isolation on read

   A user in organisation A cannot read organisation B's rows.

2. Check 2

   Cross-user write denial

   No insert, update or delete of rows that belong to another user or organisation.

3. Check 3

   Signed-out read denial

   Someone who is not logged in cannot read the tables you mark as protected.

4. Check 4

   Signed-out write denial

   Someone who is not logged in cannot add, change or delete anything.

5. Check 5

   No self-promotion

   A user cannot edit their own role, organisation or owner column to give themselves more access.

6. Check 6

   Structural checks

   Tables left open in exposed schemas, policies that say 'allow everything', and update rules with no check on the new values.

7. Check 7

   File storage, bucket by bucket

   For each storage bucket you declare, we try to list, download, upload, replace and delete other users' files, signed in and signed out, the way the Supabase storage service does.

8. Check 8

   Secrets in browser code

   A pattern scan of your source for known key formats (such as a service-role key or a JWT signing secret) in code that ships to the browser, or read through a browser-exposed environment variable. It finds known formats only. It does not find every secret, and a scan with no match is not a clean bill of health.

You can add up to three claims of your own. Server code that bypasses these rules, such as functions that use the service-role key, is not part of the checks: the dossier lists it as not checked.

• The dossier. A dated HTML report. A plain-language summary first, then each claim with its verdict, the strength of the evidence, any example that broke it, and a fix hint.
• Honest verdicts. Every claim is marked Failed (we found a concrete case that breaks it, with a replay seed), Tested (no counterexample across the generated scenarios we tried, with the number stated, which is evidence and not a mathematical demonstration) or Not checked (listed explicitly).
• A 30-minute readout call to walk through the results with you, your developer or your investor.
• Delivery in five working days from receiving access to your schema.

The dossier lists these in its own section, so nobody reads more into it than it says.

• Your live database, live app or production traffic. We do not probe or scan them.
• Storage beyond the declared buckets' folder rules: signed-URL expiry, file size and type limits, and buckets you did not declare.
• Secrets outside the scanned source: .env files (never opened, by design), your deployed site's live bundle, git history and server-side settings.
• Edge functions, server code and API routes, including anything that uses the service-role key.
• What your web or mobile app does with the data it receives.
• Sign-in provider settings (password rules, magic links, OAuth).
• Dependencies and infrastructure.
• Business logic outside the agreed claims.
• Anything that would count as a penetration test.

A Preflight check is a scoped test of named claims. It does not promise your app has no security problems, and it is not a certificate of any kind.

• Payment: 50% to book, 50% on delivery of the dossier.
• If we do not deliver within five working days of receiving access, you get a full refund.
• Your schema and code stay on Halbon Labs systems for the engagement and are deleted 30 days after delivery, unless you ask us to keep them for a re-check.
• Halbon Labs Ltd, registered in England and Wales.

Not sure yet? Take the free triage first. Prefer to talk first about payment? Email hello@halbonlabs.com.

• What do you need from me?

  Three things: a read-only export of your database schema and policies (your migrations folder, or the output of supabase db dump --schema-only), read-only access to your app's source code, for the secrets scan (a read-only repository invite is enough), and your written permission to the agreed scope, which is part of booking. No production passwords, no keys, no customer data.

• Will you touch my live app or database?

  Never. We work from the schema and code you send, loaded into a throwaway local database with made-up users and rows. Your production system and your customers' data are not touched, scanned or probed.

• Do I need to give you my Supabase password or service-role key?

  No, and please do not send either. If you paste one by accident, tell us and rotate it.

• What is not checked?

  Everything in the 'What is not checked' list above, and it is also in the dossier so nobody reads more into it than it says. In short: the live system, edge functions and server code, sign-in provider settings, secrets outside the scanned source, dependencies and anything that would count as a penetration test.

• The Lovable scan and Supabase Security Advisor say I am fine. Why pay?

  Those tools are worth running, and you should keep running them. They mostly tell you whether row-level security is switched on. They do not test whether your rules actually keep one customer's rows away from another's. That is the question an investor, a buyer or an enterprise questionnaire asks.

• Is this a penetration test?

  No. It is narrower: a written list of access claims, each with a verdict and evidence. If you also need a penetration test, we will say so on the triage call.

• What if you find problems?

  Each failed claim comes with an exact example your developer (or your AI builder) can replay, and a hint for the fix. You can fix it yourself, or we quote a fixed price from the dossier. A re-check of every fixed claim is included.

• Can I show the dossier to investors, buyers or customers?

  Yes, that is what it is for. It is dated, carries a content hash for every piece of evidence, and it states its own limits plainly so the reader can trust what it does say.

• My app is not on Supabase.

  Then this is not a fit yet. Tell us your stack on the triage call and we will say honestly whether we can help.

• Who does the work?

  Dan Tinsley, founder of Halbon Labs Ltd, with 12 years of enterprise development across TypeScript, Next.js, NestJS and Supabase. The checks run on Halbon Labs' own verification engine.