Ship Live

Shipping live is mostly an environment-parity problem plus a buyer-safety problem.

Before you launch

Make sure all of this is true:

• the release candidate is already integrated on dev
• the dev -> main release PR is the thing that changes production
• feature branches have already proven code correctness in preview-only checks
• the marketing page is clear enough to buy from
• auth works in the real deployed environment
• checkout returns to the deployed /checkout/success
• the live webhook is registered and verified
• users with granted access reach /start
• the first protected flow is usable after access appears

Production checklist

1. Land feature work into dev and make sure the release candidate is the code you want to ship.
2. Run bun run check from the repo root before opening the release PR.
3. Open a pull request from dev into main.
4. Merge only after required GitHub checks pass.
5. Confirm Vercel creates the production web deploy from main.
6. Confirm GitHub Actions runs Convex Production Deploy for the same main merge.
7. Register or verify the live Stripe webhook endpoint.
8. Run a safe billing-handoff pass in the deployed staging dev or production environment.
9. Confirm product-access grant happens in the deployed environment, not just locally.
10. Confirm the buyer reaches the protected product after payment.

For this repo, the safest staging or production billing proof is a live no-cost Checkout run using a restricted 100% off promotion code:

• single-use when possible
• short expiry
• restricted to the QA customer if possible

That verifies the part we actually care about in staging or production:

• Checkout Session creation
• hosted Checkout completion
• redirect into /checkout/success
• live Stripe webhook delivery
• Convex product-access grant
• redirect into /start

It does not prove live card charging or decline behavior. Keep card-path confidence in sandbox or local Stripe testing.

The live Stripe webhook must not point at the app origin unless that route really exists. In this repository, the real production webhook handler is the Convex HTTP-actions route:

https://<your-convex-production-deployment>.convex.site/stripe/webhook

Before trusting production billing, verify both of these are true on the production Convex deployment:

• STRIPE_WEBHOOK_SECRET
• STRIPE_SECRET_KEY

After those are correct, run one fresh live no-cost order and verify it auto-forwards back into /start without replaying the Stripe event. The replay path is a valid repair tool, but the clean production proof is the automatic delivery path.

Keep these in mind

• This repo currently assumes the buyer completes checkout in the same signed-in browser context used to read access state.
• If you change auth apps, webhook secrets, or Stripe accounts, re-verify the handoff instead of assuming it still works.
• Hotfixes are allowed to merge into main, but they must come from a hotfix branch and be merged or cherry-picked back into dev immediately afterward.
• Dedicated Convex-backed preview environments are not part of this release workflow yet. Non-dev and non-main Vercel branches stay frontend previews only.
• Do not promise a support or access path in public copy unless it actually exists.

What success looks like

Production is ready when a brand-new buyer can understand the offer, buy cleanly, get access without confusion, and start the product immediately, and when the release can be traced cleanly back to the main merge that triggered both the Vercel production deploy and the Convex production deploy.