Why we use Supabase as our entire backend

Most teams reach for a custom backend too early. Express, NestJS, Fastify — they add complexity before you need it.

For mymuaythai.app, we went all-in on Supabase. Here's what that means in practice:

Auth

Supabase Auth with PKCE flow for iOS (critical — the standard flow silently fails on iOS WebViews). Magic links for web. Social auth (Google, Apple) for mobile.

Database

PostgreSQL with Row Level Security as the authorization layer. No middleware auth checks — the database itself enforces who can see what. This is a massive simplification.

Real-time

Supabase Realtime for the chat feature. No WebSocket server to manage. Subscribe to a channel, get messages. The Thai ↔ English translation happens in an Edge Function before the message hits the database.

Edge Functions

Business logic that doesn't belong in the client: payment webhooks, translation, email notifications, scheduled jobs. Deno runtime, deployed globally.

The tradeoff

You're locked into Supabase's patterns. Complex queries sometimes need raw SQL. The Edge Functions cold start can be noticeable. But for 90% of what we need, it's faster to ship and easier to maintain than a custom backend.

The key insight: the best backend is the one your team can ship with. For a two-person team building a multi-surface product, Supabase is that backend.