You rest. We take the nightshift.
We check one thing in multi-tenant apps: whether one customer's account can reach another customer's data.
For multi-tenant web apps, any stack, often built fast on Supabase or Lovable. With your written OK, we sign up two test accounts like any new customer, test from the outside, and show you the proof.
Request a free first scanConsent-first. Designed to minimise impact: two labelled test accounts, nothing else intentionally touched. No code access needed.
The problem
Most testing happens as a single user, so everything looks right. The bug only appears across accounts: user A opens a record, changes the ID in the URL or the request, and gets user B's data. The cause is usually small: a missing access rule, a query scoped to the wrong field, an ID that isn't checked. It doesn't throw an error and it doesn't show up in a demo. It shows up when a customer sees someone else's invoice.
We test one thing, properly: whether one customer's account can reach another customer's data. That covers broken access control, IDs that aren't checked, and missing or misconfigured row-level access rules (RLS).
We don't test for every kind of bug, and we don't promise to find every issue. We don't need your source code. We don't intentionally access or change anything outside our own two test accounts.
How it works
Nothing starts without your written OK.
We start only after your written OK. Then we sign up two test accounts through your normal signup, or use logins you give us if signup is closed or paid.
We reach your app the way a real user does. No source code, no installs. We don't intentionally access or change anything outside our own two test accounts; anything beyond reading is opt-in.
Every finding is reproduced before we report it, with proof and a fix direction. One free re-check after you fix anything we find.
Your data
We show that a leak exists, never what's in it.
Who it's for
It's a common gap in apps built fast on Supabase or Lovable.
Your app works perfectly when you're the only one logged in. Find out whether one customer's account can reach another customer's data before a customer does.
You build fast, for many clients, on shared multi-tenant stacks. Find the issue in a scan, not in an angry email from your client's customer.
FAQ
Testing starts only after a founder, director or named CTO/security lead replies "I confirm" to our scope email, which sets the dates, the request rate and anything off-limits. We then sign up two labelled test accounts through your normal signup, the way any new customer would. We add only those two accounts and a few test records labelled NIGHTSHIFT TEST inside them. We don't intentionally access or change anything else, and we don't run load or stress tests, invite users, message anyone, touch billing or seats, add webhooks or integrations, or post anything publicly. We don't intentionally read, copy or keep your customers' real data, and if we come across any, we stop and don't keep it; proof is limited to row counts, record IDs, tenant IDs and column names.
No. We test from the outside, the way a real user reaches the app. Nothing to install, no repo to share.
Every finding is reproduced before it goes in the report, and each one comes with the proof.
No, and we don't promise to. We show you, reproducibly, where your app leaks data between accounts.
Your first scan is free: two labelled test accounts we sign up ourselves, designed to minimise impact, and one free re-check after you fix anything we find.
Request a free first scanPlease don't send passwords in your first message.