Discuss your projectContact
SaaS · Finland

Multi-tenant SaaS on Supabase, built with AI coding agents

Workspaces, roles and invites for a knowledge base SaaS, with access rules enforced in the database and tested at every layer

Industry
SaaS
Geography
Finland
Type
Web
Database tests
127 pgTAP checks
Coverage of SQL and function code
100%
Access policies
13
Technologies
  • Supabase
  • PostgreSQL
  • Row Level Security
  • Edge Functions
  • Deno
  • TypeScript
  • pgTAP
  • GitHub Actions
  • Claude Code
Multi-tenant SaaS on Supabase, built with AI coding agents

Project overview

A knowledge base SaaS where each customer company works in its own workspace. Members read and write articles, admins invite people, owners manage roles. In a product like this, one access mistake means a company sees another company's documents, so the rules can't live only in the frontend or in API handlers that someone may forget to update.

We built a Supabase version of its workspace, role and invite layer. Postgres Row Level Security enforces access, rules that span several rows live in the database, and an Edge Function sends invites without admin privileges. AI coding agents in Claude Code wrote the code under our usual process: a plan approved by a developer, tests before code, review by separate agents and by a developer, and CI.

What we did

  1. Role model: three roles per workspace (member, admin, owner) with a strict hierarchy, where each role manages only the roles below it

  2. Row Level Security on every table plus explicit per-column grants, because default grants leave TRUNCATE open and TRUNCATE ignores RLS

  3. Rules in the database: a workspace always keeps an owner, even when two owners leave at the same moment; an invite works once, expires in 7 days and needs a confirmed email; a deleted account hands its workspaces to the longest-standing admin

  4. Invite Edge Function that runs with the caller's token instead of admin keys, so the database decides who may invite

  5. Tests before code: pgTAP checks for every policy and role, unit tests for the function, an end-to-end run on a local Supabase stack, and CI that fails below 100% coverage

  6. Independent review: security and database reviewer agents tried to break the access model; every finding was fixed or documented as a deliberate trade-off, and each fix that changed behavior got a regression test

Key results

100% statement and branch coverage of database functions and the Edge Function code, enforced in CI

Each of the 13 access policies has a test where access is allowed and a test where it is denied

Five main issues found by reviewer agents, all fixed, with regression tests for the four that changed behavior

An unfiltered article list on 600,000 test rows takes 0.44 ms instead of 57 to 73 ms

Many apps started in Lovable and similar AI builders run on Supabase, and their access rules often need a second look. We review and rebuild that layer the same way: policies tested for every role, invariants kept in the database, and an independent review before anything ships. The process itself is described in How we build software with Claude Code agents.

Frequently asked questions

How do you test Row Level Security policies?

With pgTAP tests that act as each role and as an outsider. Every policy has at least one case where access is allowed and one where it is denied. Under RLS a denied update or delete raises no error and simply changes no rows, so the tests count affected rows instead of only checking the data afterwards.

What do the reviewer agents do?

They are separate Claude Code agents that did not write the code: one reviews security, the other the database. They get the code and the scope, not the author's reasoning, and they confirm findings with queries against a local stack. On this project they found five main issues and several smaller ones, including email confirmation switched off in the auth config.

Can you do the same for an existing Supabase app?

Yes. We audit the policies, grants and database functions, write tests for the access model as it should work, and then fix whatever fails. Apps generated with AI builders often need this.

Find out what a project like this would cost

Discuss your project

Tell us about your goals — we’ll outline the team, scope and timeline.

More case studiesAll case studies

Read the full case study Discuss your project