Then the Series A diligence call landed. Their CTO opened DBeaver, connected with the public anon key, and SELECTed across tenants. Row-level security was off on four of seven tables. The deal stalled while we rebuilt every policy.
Service Supabase development services · Postgres + RLS + Edge · UK
Supabase development for the MVP that wants RLS. done right.
Supabase Auth + Postgres + RLS + Edge Functions apps with hardened row-level security, real migrations, and a clear path to self-hosted Postgres when you scale. A senior engineer reads your brief and writes back inside a day.
17Supabase apps since 2019
0RLS audit fails
99.95%uptime SLO held
(Why CTOs sign for Supabase)
You don’t need another Supabase team. You need engineers who’ve shipped 17 Supabase apps and watched what breaks at scale.
RLS on isn’t RLS right. We build Supabase apps where a cross-tenant query is architecturally impossible, not just unlikely, and we test every policy with pgTAP before it ships.
0
<800ms
0
The CTO this page is for4 of 7 tables open · Series A stalled
Eleanor built her SaaS on Supabase. RLS was on. She thought it was fine. Then a customer queried another tenant’s data.
The CEO asked the obvious question: “Why did we ship multi-tenant SaaS with the door open?” Because RLS on isn’t RLS right, and nobody had tested the policies the way an acquirer’s CTO would.
We audited the policies, found six holes, rewrote them with proper tenant isolation, added integration tests for every policy, and shipped over 6 weeks. The IDOR risk closed. This page is for CTOs who recognise themselves in that paragraph.
How a Supabase build runs
The build, step by step
Every Supabase app we ship moves through the same ordered steps. RLS and tenant isolation come first, features come last. The order is the point.
Step-01
Audit the RLS map
We connect with the public anon key the way an acquirer’s CTO would, and try to SELECT across tenants. Every hole gets logged before a line is written.
Step-02
Pin the tenant in every policy
Tenant pin enforced in the data layer, RLS rewritten so a cross-tenant query is architecturally impossible, not just unlikely.
Step-03
Test policies with pgTAP
Every policy gets a pgTAP test that runs on every PR. Per-tenant tests gate the build so the leak can’t come back later.
Step-04
Gate the keys, wire Edge Functions
anon-key stays RLS-gated, service-role-key never reaches the client. Edge Functions handle every privileged operation, pre-warmed via cron.
Step-05
Tune Supavisor, add observability
Transaction-mode pool tuned per workload, storm-tested in CI. Sentry plus Logflare plus slow-query alerts wired before the first feature.
Step-06
Write the off-Supabase path
The migration path to self-hosted Postgres plus Auth0 lands in an ADR on day one. Schema and RLS portable, lock-in fear ends.
The stack we ship every Supabase build on.
Supabase Auth, Postgres, RLS, Edge Functions, and pgTAP handle 99% of what a multi-tenant SaaS needs on day one. The rest is reached for, not assumed.
T1
What every Supabase build runs on
Supabase coreSupabase AuthPostgres + RLSEdge FunctionsSupabase RealtimeSupabase StoragepgvectorDrizzle + Kyselysupabase-js + CLIpgTAPSentry + LogflareMixpanelGitHub Actions
T2
When your Supabase brief calls for it
reach when neededPythonJavaGoGraphQLtRPCPrisma / Drizzle
T3
The infrastructure layer
AWS-defaultAWSCloudFrontCloudflareAWS LambdaS3 + CloudFrontAWS RDS / AuroraRedisInngest / Trigger.devTerraformDatadog + SentryVault + KMSPgBouncer
Supabase foundations.
Day one, not month ten.
Every Supabase app we’ve shipped since 2019 makes the same six load-bearing decisions before a feature gets written. Each one is hard to retrofit. Open any row.
Tenant pin enforced in every policy, RLS rewritten in supabase-migrations and tested with pgTAP on every PR. A cross-tenant SELECT is architecturally impossible, not just unlikely. Diligence-defendable.
Postgres and indexes do the work. Realtime where it earns it, Edge Functions where the latency earns it. We don’t reach for a system because a tutorial said so, we reach for it when the numbers say so.
anon-key stays RLS-gated, service-role-key never reaches the client. Every privileged operation runs inside an Edge Function, pre-warmed via cron so cold start stays under 400ms and the customer never notices.
RLS enforced on Realtime payloads, channels scoped per tenant. A subscription can’t leak another customer’s rows. The cross-tenant leak is impossible on the socket too, not just on the query.
Auth tied to the tenant pin so identity and isolation are the same decision. Schema changes flow through supabase migration only, SQL editor read-only in prod, CI checks parity so drift can’t creep in.
Sentry plus Logflare plus structured logs and slow-query alerts, wired before the first feature. On-call reads the trace and knows what fired in 60 seconds, not three days.
Supabase work we do
What we work on
The Supabase surfaces we ship for UK SaaS, fintech, and B2B teams.
0
Cross-tenant queries left open
17+
Supabase apps since 2019
“P99 dropped from 1.4s to 180ms. The bill cut a third. Best engagement we’ve paid for.”
001
RLS audits + rebuilds
We connect with the anon key the way an acquirer would, find every hole, and rewrite the policies so the leak is architecturally impossible.
002
Full Supabase build sprints
Auth, Postgres, RLS, Edge Functions, pgTAP and Logflare. Tested isolation, observable from day one, two senior engineers paired.
003
Supabase migrations + rebuilds
Take an existing Supabase codebase and rebuild it for production behind a flag. Tenant pin at the data layer, anon-key gated by policy.
004
Supavisor + performance tuning
Transaction-mode pool tuned per workload, connection storms designed out and storm-tested in CI. Pool exhaustion ends.
005
Off-Supabase migration paths
A documented path to self-hosted Postgres plus Auth0, written on day one. Schema and RLS portable, it’s just Postgres. Lock-in fear ends.
Results
Eleanor’s RLS rebuild,
Eleanor’s RLS rebuild,
in real numbers
We audited the RLS policies, rebuilt the tenant pin at the data layer with pgTAP, wired the Supavisor pool, and added Edge Functions for privileged operations. Twelve-week sprint. The Series A diligence call cleared in three days, not three weeks.
RLS rebuild
6
Policy holes closed
0
Cross-tenant queries left open
Latency
1.4s180ms
P99, after rebuild
−1/3
Supabase bill cut
Track record
17
Supabase apps since 2019
99.95%
Uptime SLO held
What they say six months after launch
Senior Supabase development, measured on real traffic, not local dev.
100%
would refer us
P99 dropped from 1.4s to 180ms. The bill cut a third. Best engagement we've paid for.
What CTOs actually ask before signing
Pain-first, soft-second.
Because RLS on isn’t RLS right. Eleanor had it on and still leaked across tenants because four of seven tables weren’t actually gated. Our audit connects with the public anon key, the way an acquirer’s CTO will, and tries to SELECT across tenants. If it works, you have a hole. We rewrite every policy, pin the tenant in the data layer, and test it with pgTAP so the leak is architecturally impossible, not just unlikely.
Stay if it’s working. Supabase carries most UK SaaS a long way, and we tune the Supavisor pool, indexes, and Edge Functions before anyone talks about leaving. When the bill or the scale genuinely warrants it, you already have a documented path to self-hosted Postgres plus Auth0 because we wrote it on day one. The schema is portable, it’s just Postgres, and the RLS is portable too. No lock-in, no surprise rebuild.
pgvector under about 5M vectors, because keeping embeddings in the same Postgres you already run is one fewer system to secure, back up, and pay for. Beyond that, Pinecone or Qdrant, with the decision written into an ADR and a migration path attached. We don’t reach for the dedicated vector DB on day one because a tutorial said so. We reach for it when the numbers say so.
Yes. We’ve done it for UK clients in 2025. Your existing backend (Rails, Django, .NET, Java, Go) stays. We build the Supabase development layer with typed contracts and RLS so the two sides talk safely. You get senior-grade Supabase without rebuilding the backend you already trust.
30-day walk-away both ways. Milestone billing 25/25/25/25. UK VAT registered, listed on Companies House, shipping since 2019. You’re never more than four weeks at risk of paying for nothing, and the IP assigns to you on every commit.
Every Supabase project has two senior engineers paired, not one. Every decision goes into an ADR the same day. Mohit reviews every PR. In seven years, two engineers have left mid-project. Both handovers were inside 48 hours, and neither client noticed.
Yes, with 14 days’ notice. Engineers move to other projects. Spend pauses. Resume with 14 days’ notice. No cancellation fee. No restart fee.
Yes, with mutual agreement. Several of our engineers have moved in-house to client teams over the years. The contract has a clean intro fee built to make the transition friction-free, not punitive. We’d rather you have a great in-house team than be locked into us forever.
NDA signed inside 30 minutes via DocuSign. Mutual NDA template ready. Send the brief once it’s in place.
In context
Inside the work.
A look at the kind of supabase development surface we hand over — real screens, real data, documented and yours from day one.
One paragraph. That’s it.
Tell us what the build needs to do, who uses it, and what success looks like. Mohit replies inside 24 hours: a clear yes, a clear no, or the one question that decides it.
What happens after the email lands
- < 24h
A personal reply.
Yes, no, or the deciding question. Straight to your inbox.
- Week 1
Audit week begins.
RLS map, tenant-pin strategy, pool tuning, signed scope.
- Launch
Holds on Tuesday.
RLS pgTAP-gated. Cross-tenant leak architecturally impossible.