What a Supabase developer actually fixes (RLS, auth, leaks)

A Supabase developer is not “someone who clicked Auth once.” The job is PostgreSQL design, policies that hold under real roles, and fixing apps where RLS was skipped. Lovable and Replit frontends are fine — the database must still be correct.

#Typical engagements

• RLS audit and rewrite after a data leak scare.
• Auth: email, OAuth, roles, email verification.
• Schema + migrations before the product grows.
• Realtime, storage, edge functions with security reviewed.

#Quick self-check

Supabase health:
[ ] RLS enabled on every user table
[ ] No service_role in the browser
[ ] Two-user isolation test passed
[ ] Migrations in git, not only dashboard clicks

#Frontends I connect to

Lovable, Next.js, Replit, and other React apps. The backend patterns stay the same. If your UI is Lovable-specific, the Lovable + Supabase page may fit better; pure backend/auth work lives on Supabase Developer.