Designing application architecture with Next.js and Supabase
How I structure App Router products so UI, domain logic, Postgres, and security stay maintainable as the product grows.
Next.js and Supabase are a strong pairing for product teams that need to move quickly without giving up a real database. The failure mode is putting everything in page components and RLS-blind queries. The success mode is a thin UI over deliberate domain boundaries.
On Find Flag Football I keep a layered approach: routes and API handlers at the edge, application use cases for workflows, repositories for persistence, and ports/adapters for Stripe and email. Pure registration policy lives outside Supabase client code so business rules can be tested without a database session.
Supabase Auth and Postgres RLS are part of the product design, not an afterthought. Registrations, posts, gallery media, and admin tools each need explicit access rules. If a Solutions Engineer is evaluating a customer’s “we’ll put it in Supabase,” the first question should be how tenancy and authorization are modeled, not which UI library they chose.
Server-first data loading for public discovery, with careful caching and invalidation, keeps the product fast for anonymous visitors while authenticated surfaces stay dynamic. Architecture is the set of decisions that keep those two modes from colliding.