Set Up DB, Auth, and Payments

Once the marketing surface is clear enough, wire the dynamic stack in this order:

1. Clerk
2. Convex
3. Stripe

Why this order matters

Clerk identifies the user. Convex stores product access and product state. Stripe finishes the payment flow. If those three systems do not agree on the same user and environment values, checkout can look successful while access still fails.

The plain-English version

• Clerk is your identity system.
• Convex is your app state and product-access system.
• Stripe is your payment system.
• Environment variables are the private keys and URLs that let those systems talk to each other.

The setup path

1. Follow Clerk + Convex Auth.
2. Confirm the Clerk JWT template is named exactly convex.
3. Run bun run dev:convex so .env.local gets the current NEXT_PUBLIC_CONVEX_URL and CONVEX_DEPLOYMENT values for your hosted Convex dev deployment.
4. Follow Stripe Checkout + Webhook.
5. Create the Stripe product and price from the repo scripts.
6. Start the Stripe dev listener and let it sync the current webhook secret plus Stripe secret into your hosted Convex dev deployment.

Safety rules

• Start in test mode or a safe sandbox first.
• Do not start with live Stripe mode.
• Restart the app if the Stripe listener writes a new webhook secret.
• Keep the app and Convex on the same webhook secret and Stripe secret key.

What success looks like

You are wired correctly when:

• sign-in works
• protected routes can read viewer state
• checkout starts from the app
• the webhook grants product access
• /checkout/success eventually routes the buyer into /start