Supabase RLS in a multi-tenant rebuild

Supabase RLS in a multi-tenant app is where most of the real design work hides, because every table has to answer the same question on every request: which organisation does this row belong to, and is the person asking inside it. Team Feel is a platform where companies run structured mutual-rating sessions across their departments, and its second version was a full rebuild in five weeks that grew its access-control surface from 47 policies to 77.

The rebuild carried the same schema forward, which is what made five weeks possible. Tables that already encoded which company owned what did not have to be redesigned, only protected more thoroughly. The growth from 47 policies to 77 happened on top of that schema, so the added effort went into the boundary between companies rather than into reshaping the data underneath it.

The stakes are specific to what the product holds. People rate the colleagues they actually work beside, and the results become engagement scores, talent signals and calculated bonuses. A policy gap in most apps leaks a record. A policy gap here shows one company’s ratings, or one colleague’s scores, to someone who should never see them, and the product only works if the people rating believe that cannot happen.

That is also why the score is computed server-side rather than in the browser. A bonus figure calculated on the client is a figure a determined user can change before it is saved. Computed on the server, behind the same policies that decide who can read the inputs, the number a company pays against is one nobody in the session could have edited.

Multiple companies, billing and referrals were designed in from the first version rather than bolted on later, which is the other half of why a rebuild could keep the schema. Tenancy decided on day one shapes the tables, while tenancy added afterwards has to reshape them. The evaluation cycle and the graphs it produces are in the Team Feel case study.