Supabase has become a popular way to build web apps quickly. You get a real Postgres database, user authentication, file storage, realtime updates and serverless functions in one place, with a generous free tier to start. For founders and small teams, it removes a lot of backend setup.
But "quickly" can turn into "insecure" if the details are skipped. The most common Supabase problem I see is a database left open because row level security wasn't set up properly.
I'm Aldrian, an independent developer in the Philippines. I build web apps on Supabase, and I help teams fix and secure existing Supabase projects.
What Supabase provides
- Postgres database: a mature, reliable SQL database
- Authentication: email and password, magic links, social logins and more
- Row level security: rules in the database that decide who can read or change each row
- Storage: file uploads with access policies
- Realtime: live updates when data changes
- Edge functions: server-side code for webhooks, integrations and private logic
What I build with Supabase
- SaaS products and MVPs. See micro-SaaS development.
- Client portals and member areas
- Internal tools and admin dashboards
- Booking and request systems
- Realtime apps like live dashboards and collaboration tools
- Mobile-friendly PWAs
Security done right
Row level security on every table
In Supabase, the browser can talk to the database directly, using a public key. That's safe only if every table has row level security enabled with correct policies. Without them, anyone with your public key can read or change data they shouldn't. I enable RLS everywhere and write policies that match your rules: users see only their own data, admins see more, and so on.
Service keys stay secret
The service role key bypasses all security rules. It must never appear in front-end code. I keep it in server-side functions only, stored as a secret.
Sensitive logic on the server
Payments, permissions changes and anything that shouldn't be trusted to the browser runs in edge functions or a separate backend.
Storage policies
File buckets get access policies too, so private files stay private.
Tested policies
I test policies by trying to access data as different users, including users who shouldn't have access. Security rules you haven't tested are just hopes.
Security is central to my work. I built Jibong Purr-tection, a WordPress security plugin on WordPress.org, and Ghostly, an encrypted chat app where the server only stores ciphertext.
Clean database design
- Clear tables, relationships and constraints
- Migrations tracked in version control
- Indexes for the queries your app runs
- Database functions and triggers only where they genuinely help
- Generated TypeScript types so the front end matches the database
Front ends that feel fast
I pair Supabase with React, using frameworks like Next.js or React Router, and TypeScript throughout. Pages load quickly, data updates smoothly and realtime features appear only where they add value.
Supabase or something else?
Supabase is a great fit for many apps, but not all. I also build on Cloudflare Workers with D1, and on traditional Postgres or MySQL backends. My own website and Ghostly run on Cloudflare. I'll recommend Supabase when its built-in auth, Postgres features and realtime save real time, and something else when they don't. More on custom web apps.
Fixing existing Supabase projects
Many projects start fast and accumulate problems. I can help with:
- Auditing and fixing row level security
- Moving secrets out of front-end code
- Cleaning up schemas and adding migrations
- Fixing slow queries and adding indexes
- Moving logic from the browser to edge functions
- Setting up backups and environments for development and production
Common Supabase mistakes
RLS disabled "for now." It tends to stay disabled. Enable it from day one.
Service key in the front end. It gives full database access to anyone who looks.
Policies that are too broad. "Authenticated users can read everything" is rarely what you want.
No migrations. Changes made by clicking in the dashboard are hard to track and repeat.
Using one project for development and production. Test data and real data mix, and mistakes reach users.
Development and production environments
Professional Supabase projects use separate environments: one for development and testing, one for real users. Schema changes are written as migrations, tested in development and then applied to production in a controlled way. It takes a little more setup at the start and prevents the most painful kind of mistake, a change that breaks the live app for everyone.
Keeping costs predictable
Supabase pricing depends on usage, like database size, storage, bandwidth and active users. I design apps to use resources sensibly, with efficient queries, compressed files and sensible limits, and I'll explain what affects your bill so there are no surprises as you grow.
What it usually costs
It depends on the app's features. A focused MVP on Supabase can be built efficiently because so much is provided. Security audits of existing projects are smaller fixed-price jobs. You'll get a quote after we talk.
How we'd work
- Tell me about your app or existing project.
- I review the requirements or audit the current setup.
- You get a quote with timeline and fixed price.
- I build or fix, with preview links.
- We test security policies and features.
- We launch, with documentation and handover.
Let's build on Supabase, securely
Tell me about your project. I'll reply with a plan and a fixed quote.
