The security thing nobody explains and everybody needs

I was testing Fokas a few months ago and I realized I could, if I really wanted to, write a query that pulled another user's data. Not because I was trying to hack my own app — I was just testing edge cases the way you do when you're a backend engineer who knows where things break. But the fact that it was even possible meant I had a real problem and I needed to fix it before anyone else's data was in there.

Row-level security. If you're building anything that has multiple users and each user should only see their own stuff — a SaaS, a coaching platform, a multi-tenant anything — RLS is the thing you need to understand before you ship. I'm not exaggerating when I say most tutorials skip this. They'll walk you through setting up auth, setting up a database, connecting the two, and then just kind of... wave at the security part like it'll figure itself out. It won't.

Here's how I explain it to people because the official docs make it sound more complicated than it is. Imagine a club, right. There's a bouncer at the door and he's got a list. Every time someone tries to get in he checks their name against the list and either lets them through or doesn't. Row-level security is that bouncer, except the "club" is your database table and the "list" is a policy you write that says "this user can only see rows where the user_id column matches their own ID." That's it. That's the whole concept. The database enforces it automatically at the query level, so it doesn't matter how a request comes in — direct query, API call, whatever — the wrong person cannot see the wrong data.

I learned this building Fokas, which is my SaaS for coaches and creators. Multi-tenant means multiple coaches, each with their own clients, their own content, their own data — and none of them should ever see each other's anything. If I got that wrong, I don't have a product, I have a liability. And because I'm using Supabase, the setup is actually not bad. You write a policy in plain SQL and Supabase handles the enforcement. Something like: create policy "users can only see their own rows" on your_table for all using (auth.uid() = user_id). One policy. That table is now locked down.

The thing I want people to take from this is not that security is scary and complicated — it's that it doesn't have to be, and it's not optional. I see a lot of solo builders move fast and skip things like this because they want to ship and I understand that impulse, I have that impulse every single day. But shipping with a security hole is worse than shipping late. The time you spend adding RLS before your first real user is a fraction of the time you'll spend managing the fallout if you don't.

Supabase has a whole section in their docs specifically on RLS and they have good examples for the most common patterns — user-scoped data, team-scoped data, public read with authenticated write, all of it. Read that section before you add your first real user to anything you're building. That's the actual advice right there.

Supabase RLS — it's built right into the Supabase dashboard and the docs are genuinely one of the better pieces of technical documentation I've read. You can find the RLS guide at supabase.com/docs/guides/database/postgres/row-level-security. If you're already using Supabase for your project, you have zero excuse to not have this set up because it's right there. If you're not using Supabase yet, this feature alone is a pretty good reason to look at it.

The thing I like is that you can test your policies directly in the Supabase SQL editor by impersonating different users — so you can verify that the bouncer is actually doing his job before you go live. That step alone saved me from at least one "oh no" moment during Fokas development.

If you're building anything with user data, please learn this before you ship — I mean that. And if you want my full setup for building with Supabase, auth, RLS, the whole thing — that's what my Ship It course covers. It's one-ninety-seven and you walk out with a deployed app. yessieperez.com.

Yesenia M. Perez Lead Backend Engineer. Mom of 3. Building at 11pm.

yessieperez.com | IG @yeseniavperez | TikTok @iamyessieperez | LinkedIn /yessiemalone