Persona Library
← All personas
supabasetechnicalAPP-130

The Supabase Indie Hacker

#supabase#indie-hacker#backend#postgres#auth#startup
Aha Moment

The shift was quiet. They'd been using supabase for weeks, mostly out of obligation. Then Postgres database with Row Level Security solved a problem they'd been routing around — and suddenly the friction of row Level Security policies that are powerful but hard to debug when queries return empty results felt absurd. They couldn't go back.

Job Story (JTBD)

When I'm the indie hacker's product just got posted on hacker news, I want to ship an MVP in days, not weeks, with auth, database, and storage working out of the box, so I can use Row Level Security to handle authorization without building a custom permission layer.

Identity

A solo developer or indie hacker building a SaaS product where Supabase is the entire backend. They chose Supabase because it gives them Postgres, auth, storage, and real-time out of the box — and they can ship their MVP in a weekend instead of a month. They write SQL directly, use Row Level Security because they have to, and treat the Supabase dashboard as their admin panel. They are building a business alone and Supabase is the co-founder that handles the backend.

Intention

To make supabase the system of record for ship an MVP in days, not weeks, with auth, database, and storage working out of the box. Not aspirationally — operationally. The kind of intention that shows up as a daily habit, not a quarterly goal.

Outcome

The tangible result: ship an MVP in days, not weeks, with auth, database, and storage working out of the box happens on schedule, without manual intervention, and without the anxiety of row Level Security policies that are powerful but hard to debug when queries return empty results. supabase has earned a place in the daily workflow rather than being tolerated in it.

Goals
  • Ship an MVP in days, not weeks, with auth, database, and storage working out of the box
  • Use Row Level Security to handle authorization without building a custom permission layer
  • Scale from free tier to paid without re-architecting the database
  • Keep the entire backend in one platform so there's one dashboard, one bill, one set of docs
Frustrations
  • Row Level Security policies that are powerful but hard to debug when queries return empty results
  • The free tier limits that force a pricing decision before the product has revenue
  • Edge Functions that work differently from their local development environment
  • Database migrations that work in development but fail in production with no clear error
  • Real-time subscriptions that stop working silently when the connection drops
Worldview
  • The best infrastructure is the infrastructure you don't have to think about
  • For a solo developer, every hour spent on backend plumbing is an hour not spent on the product
  • If the tool forces you to become a DevOps engineer to use it, it failed its core promise
Scenario

The indie hacker's product just got posted on Hacker News. Traffic spikes 50x in an hour. The Supabase dashboard shows connection pool saturation — they're on the free tier with a connection limit they didn't know about. They upgrade to Pro in a panic, the connections stabilize, but some real-time subscriptions dropped during the spike and users are seeing stale data. They add reconnection logic, bump the pool size, and write a blog post about the experience. Total downtime: 15 minutes. Total stress: immeasurable.

Context

Uses Supabase as the sole backend for 1–3 products. Works with the Supabase JS client in a Next.js or SvelteKit frontend. Has 10–50 tables with RLS policies on most of them. Uses Supabase Auth for user management. Stores files in Supabase Storage. Runs 0–5 Edge Functions. Monitors usage through the Supabase dashboard. On the free tier or just upgraded to Pro. Spends 2–5 hours per week on backend work, the rest on frontend and product.

Success Signal

They've stopped comparing alternatives. supabase is open before their first meeting. RLS policies are version-controlled and tested as part of their CI pipeline. The strongest signal: they've started onboarding teammates into their setup unprompted.

Churn Trigger

Connecting to Postgres through IDE requires paid add-ons for IPv4. Row Level Security policies that are powerful but hard to debug when queries return empty results keeps recurring despite updates and workarounds. RLS policy complexity became a security liability — they weren't confident the policies were correct. The switching cost was the only thing keeping them — and it's starting to look like an investment in the alternative.

Impact
  • RLS policy debugging tools that show why a query returned empty results eliminate the guessing game
  • Connection pool scaling that auto-adjusts during traffic spikes prevents surprise outages
  • Migration dry-runs that test against a production snapshot before applying catch errors before they matter
  • Real-time subscription resilience with auto-reconnect and state sync prevents stale data after drops
Composability Notes

Pairs with supabase-primary-user for the team developer vs. solo builder perspective. Use with vercel-primary-user for the full-stack deployment workflow. Contrast with firebase-primary-user for the Google backend alternative comparison.