Supabase
The database rules written before the first screen
Our engineers have built four production platforms on Supabase, including workforce compliance for a UK recruiter. They start with who is allowed to read which row, and you interview them first.
What you are getting
4 things that decide this
- 01Senior engineers with four Supabase systems already in production: Shift Link, Lexpair, Trading CoPilot and ExtraaJe.
- 02They write Row Level Security policies as part of the feature, not as a hardening pass after launch.
- 03You interview every engineer before they join, and they work in your repo and your standups rather than behind a queue.
- 04You own the schema, the migrations and the policies from the first commit. Interview each engineer before they join, and decline anyone.
What a Supabase developer actually does here
Supabase gives you a Postgres database with an API in front of it. That API is reachable from the browser, which is the whole convenience and the whole risk.
Supabase's own documentation puts it plainly: Row Level Security must always be enabled on any table in an exposed schema, and public is exposed by default. So the job is policy design. On Trading CoPilot we used Row Level Security to keep each trader's data separate, with encrypted API key storage and OTP sign-in on top. On Shift Link we built right-to-work checks against the UK Government API, where the wrong row reaching the wrong recruiter is a compliance failure, not a bug.
Four builds, one habit: decide who can see a row before deciding how it looks on screen.
What they build before the first screen exists
Access policies that hold
Row Level Security per table, plus a test that signs in as the wrong user and must be refused. Policies nobody tested are guesses.
Schema and migrations in Git
Changes applied the same way in every environment. Clicking a column into the dashboard is how staging and production drift apart.
Auth wired to real roles
Sign-in, invitations and role checks that match how your business actually works, including the admin who can act for a customer.
Realtime and storage, used sparingly
Live updates where a user waits on them. Everywhere else they add reconnect logic you have to maintain for no benefit.
Edge Functions for the private work
Anything holding a secret or calling a paid API runs server-side, as on Trading CoPilot, never in a browser your users control.
- BrowserHolds a publishable key
- AuthWho is this user
- PolicyWhich rows they may touch
- PostgresThe query runs
- Edge FunctionSecrets stay here
The policy step is the security boundary. Filtering in the front end only hides rows from the screen, not from the API.
Products where the wrong row is a breach
“Their attention to detail, quality of employees, and work ethic were outstanding.”
Nicolas de Quesada · CEO, Lexpair
How hiring works
- 01
Tell us who must never see whose records
A free call about the product, the data and the boundaries in it. If Supabase is the wrong fit for what you described, we say so then.
- 02
Meet the engineers
We shortlist people who have written access policies for a live product, and you interview them your own way. Turn any of them down.
- 03
They embed
Your repo, your Supabase project, your standups. One of our engineers owns the policy layer and is named as the person who answers for it.
- 04
They hand over
Migrations, the policies and the test that tries to read another tenant's rows and must fail, plus a trained owner on your team. Where a client prefers we keep watching it, we stay on under a service level we agree.
Stack
Supabase
Around it
Practices
Bring us the schema you are unsure about
Show us the tables and who is meant to see what. The scoping call is free, and you will leave knowing whether your data is actually protected.
01Can they take over a Supabase project someone else started?
Yes, and it is a large share of this work. They audit the policies first, because that is where inherited projects are usually weakest, then fix in reviewable steps rather than rewriting what already works.
02Will we get locked into Supabase?
Less than with most managed platforms, because underneath it is Postgres. Your schema, your data and your SQL move to any Postgres host. The parts that are Supabase-specific are Auth, Realtime, Storage and Edge Functions, and an engineer who knows that keeps those boundaries visible in the code.
03Do they handle the mobile app too?
Often, yes. ExtraaJe pairs a React Native app for employees with a web dashboard for HR on one Supabase backend, and Shift Link does the same for shift workers and their agency.
04How do you keep tenants separated in a multi-tenant product?
With policies enforced inside the query, so the database refuses the row rather than the application forgetting to filter it. We then add a test that signs in as one tenant and tries to read another's data, and that test has to fail every time.
05Will they be online while our team is?
Yes, with a daily overlap agreed before the engagement starts. Policy work needs live review, because a mistake in it is invisible on screen and expensive later. The window is set during scoping and we do not quietly change it.
06What makes one Supabase build cost more than another?
How many distinct roles your data has. Two user types with clean separation is straightforward; a product where admins act for customers and partners see slices of both is where the real design sits. Scoping calls are free. Where we must audit an existing project first, a paid two-week diagnostic ends in a fixed price.
