Expo with Supabase, Supabase Auth and RevenueCat is the standard shape for a subscription mobile product built by a small team. Expo manages the native layer, RevenueCat manages store purchases and entitlements, and Supabase holds the users and the content. It suits a consumer app shipping on both platforms from one codebase.
Database
Postgres here stores the content a subscription unlocks, plus a mirror of the entitlement state RevenueCat reports. Keep that mirror in a table only an edge function may write, updated from RevenueCat webhooks, and have row level security policies join against it when serving premium rows. Supabase Storage is worth using for gated media in the same project, with signed URLs issued only after the same entitlement check has passed.
Authentication
Supabase Auth handles sign-in inside Expo through the linking scheme and a storage adapter, and its user ID becomes the identifier you hand RevenueCat when the SDK configures. Doing that at login rather than at first launch means a subscriber switching from iOS to Android signs in and finds the subscription already attached. Anonymous browsing before signup is fine provided you alias the identity once an account exists.
Payments
RevenueCat's SDK includes native store code, so an Expo project consumes it through a config plugin and a development build. Once configured, offerings and paywalls are fetched remotely, which means price and packaging changes ship without a new app release, unusually valuable when store review sits between you and every change. Entitlements then give the app and your edge functions the same answer about who has access.
The remote configuration advantage stops at the products themselves: every in-app purchase item still has to be created and approved in App Store Connect and Play Console, and sandbox testing across both is tedious. Expect the first working purchase flow to take longer than the code suggests. A development build is also mandatory, so Expo Go can verify nothing at all about your paywall.
Matched on Expo plus the parts of this stack our catalog tags. Each card shows which pieces actually line up, so you can see how much you would still wire yourself.
The rules that matter for this combination specifically, including who owns entitlement state. Adapt the commands to your repository before committing it.
# CLAUDE.md
This project is a Expo SaaS on Supabase, Supabase Auth and RevenueCat.
## Stack
- Framework: Expo
- Database: Supabase
- Auth: Supabase Auth
- Payments: RevenueCat
## Boundaries
- Never edit a migration that has already run. Write a new one.
- Never hardcode RevenueCat price or product identifiers in components. They belong in config.
- Never trust a client-supplied user id. Read the session from Supabase Auth on the server.
- Treat webhook handlers as idempotent. The same event will arrive twice.
## Entitlements
- RevenueCat is the source of truth for what a customer paid for.
- The database mirrors that state; it never decides it.
- Any check for "can this user do X" reads the mirrored entitlement, not a live API call.
## Before you say a change is done
- The app builds.
- Tests pass.
- No secret, key or webhook signing secret appears in a committed file.