Expo with Supabase, Supabase Auth and Stripe is the fastest route to a shipped mobile app that charges for real-world transactions. Expo removes the native build work, Supabase provides the Postgres and the session, and Stripe handles payment for goods and services delivered outside the app.
Database
Supabase is one of the few backends you can use from Expo without leaving the managed workflow, since it speaks HTTPS and websockets rather than shipping a native module. That matters: the client library installs and runs without a config plugin. Structure tables so the app reads its own rows through row level security, and keep Stripe order, refund and payout records in tables written only by an edge function, never by the device.
Authentication
Supabase Auth works with Expo's linking layer, so OAuth and magic link redirects return into the app through your configured scheme rather than dead-ending in a browser tab. Session persistence needs a storage adapter you supply explicitly, a five-line detail that silently logs everyone out on relaunch when skipped. Once wired, tokens refresh across app foregrounding and the same user ID keys the Stripe customer record you create server-side.
Payments
Stripe's React Native SDK contains native code, so inside an Expo project it arrives as a config plugin and requires a development build rather than Expo Go. That is the integration fact worth knowing before you start. In return you get native payment sheets, Apple Pay and Google Pay for physical goods and services, with each charge confirmed server-side by an edge function that writes the order back into Postgres.
Two constraints stack here. The app stores only allow Stripe for real-world goods and services, and the Stripe SDK's native code means adding it leaves Expo Go behind permanently. Plan for development builds and an EAS pipeline from day one instead of discovering it when the payment sheet refuses to load in the client everyone on the team has been testing with.
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 Stripe.
## Stack
- Framework: Expo
- Database: Supabase
- Auth: Supabase Auth
- Payments: Stripe
## Boundaries
- Never edit a migration that has already run. Write a new one.
- Never hardcode Stripe 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
- Stripe 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.