Next.js with Firebase, Clerk and Stripe pairs a document store built for realtime and offline with auth you do not have to design. Firestore handles collaborative and event-shaped data well, Clerk gives you sign-in and organizations on day one, and Stripe covers billing. It suits a product with live-updating screens and a team plan behind them.
Database
Firestore fits this stack when your screens are subscriptions rather than page loads: presence, chat, notifications and activity feeds update without polling. That works from Next.js client components, while server code uses the Admin SDK. Model documents around how a screen reads, not how the data relates, because joins do not exist here. Denormalize the Clerk organization ID and the resolved Stripe plan onto documents you query so access checks never need a second read.
Authentication
Clerk gives Next.js middleware-level route protection plus prebuilt sign-in, sign-up and organization UI, which is most of the reason to pick it over Firebase Authentication. Organizations matter here because Firestore security rules can then key on an organization claim instead of a user list per document. The connection is not automatic: you mint a Firebase custom token from Clerk so the client SDK reads Firestore under the same identity your middleware already validated.
Payments
Stripe attaches to the Clerk organization rather than the individual user, which is the right shape once you sell team plans. Store the Stripe customer ID in Clerk organization metadata or a Firestore document keyed by organization, then write the resolved plan somewhere your security rules can read. Stripe webhooks land in a Next.js route handler that writes through the Admin SDK, keeping billing state out of client-writable documents entirely.
You now run two user directories. Clerk holds canonical identity and Firebase holds whatever the custom token minted, so deletions, email changes and bans must be applied twice or they diverge. Add a Clerk webhook that mirrors user and organization changes into Firestore from the start. Retrofitting that reconciliation once real accounts exist is considerably less pleasant.
Matched on Next.js 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 Next.js SaaS on Firebase, Clerk and Stripe.
## Stack
- Framework: Next.js
- Database: Firebase
- Auth: Clerk
- 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 Clerk 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.