Production checklist (PRO) · Docs

Starter ProProduction

Validate the foundation before launchLink to section

Starter Pro gives you the production-shaped foundation.

This checklist helps you validate that foundation before exposing the product to real users, real payments, and real customer data.

A launch-ready SaaS should not only “build successfully”.

It should validate:

authentication
billing
backend persistence
protected routes
secure delivery
environment variables
deployment behavior
recovery paths
buyer trust

One-time payment · Instant access after purchase

Setup guide

Production rule

Do not launch because the UI looks finished. Launch when the critical systems behave correctly.

What this checklist coversLink to section

Auth

Sessions, providers, reset flows, verification, and protected routes.

Billing

Checkout, portal, webhooks, invoices, subscriptions, and access.

Backend

Database, ownership, migrations, server rules, and product data.

Launch readiness modelLink to section

Production readiness is not one check. It is the alignment of identity, payment, data, access, and delivery.

Layer	Production question
Auth	Can real users sign in safely and recover access?
Billing	Can real customers pay and have state synchronized?
Backend	Can product data persist with ownership and access rules?
Delivery	Can paid access be fulfilled securely after purchase?
Environment	Are production secrets complete and separated from local/test?
Deployment	Does the production build behave like the local validated flow?

Go-live principle

A production checklist should verify behavior, not only configuration.

ChecklistLink to section

Validate environment variablesLink to section

Confirm that local, preview, and production environments are separated.

.env.production

NEXT_PUBLIC_APP_URL=
DATABASE_URL=
AUTH_SECRET=

AUTH_GITHUB_ID=
AUTH_GITHUB_SECRET=
AUTH_GOOGLE_ID=
AUTH_GOOGLE_SECRET=

STRIPE_SECRET_KEY=
STRIPE_WEBHOOK_SECRET=
STRIPE_PRICE_STARTER_PRO_ONE_TIME=

RESEND_API_KEY=
AUTH_EMAIL_FROM=

Production secrets should not reuse local test values unless the system is intentionally still in test mode.

Validate authenticationLink to section

Test the full auth lifecycle:

credentials sign in
OAuth sign in
registration
email verification
forgot password
reset password
password change
protected route redirects
session-aware navigation
connected account behavior

Validate billingLink to section

Test the full Stripe lifecycle:

checkout session creation
successful payment
canceled payment
billing portal session
webhook signature verification
subscription created event
subscription updated event
subscription canceled event
invoice payment succeeded event
invoice payment failed event

Validate backend and accessLink to section

Confirm that product data is not only displayed, but protected correctly:

migrations run
database client is generated
seed data works only where expected
ownership checks work
protected data requires a session
paid features require valid billing state
server-side rules match UI state

Validate secure deliveryLink to section

If your product includes paid downloads or fulfillment, test:

payment confirmation
purchase-to-access mapping
private asset storage
download token creation
token expiration
unauthorized access behavior
interrupted session recovery

Validate production deploymentLink to section

Build and deploy intentionally.

terminal

pnpm build
pnpm start

Then validate the production URL:

/login
/register
/dashboard
/billing
/settings
paid access flows
webhook endpoint

Auth checklistLink to section

Required auth behavior

users can register
users can sign in
users can sign out
sessions persist correctly
protected routes redirect anonymous users
authenticated users cannot access auth pages unnecessarily

Auth security checks

forgot password does not reveal whether an email exists
reset tokens expire
provider disconnect cannot lock users out
server-side validation exists for auth actions
error messages are useful but not overly specific

Auth UX checks

loading states are visible
forms disable submit while processing
errors are field-level when possible
global auth errors are clear and calm
success states explain the next step

Billing checklistLink to section

Checkout checks

checkout sessions are created on the server
success URL works
cancel URL works
customer mapping is correct
test and production prices are not mixed

Webhook checks

webhook signatures are verified
events are handled idempotently
subscription create/update/delete events sync correctly
invoice payment events update billing state
failed payments show a clear product state

Billing access checks

paid features require active access
canceled subscriptions remove access when appropriate
past-due state is handled clearly
billing page reflects synchronized backend state
portal access is only available to the correct customer

Backend checklistLink to section

Check	Why it matters
Migrations run cleanly	Prevents broken production deploys
Prisma client is generated	Ensures typed database access
Auth models are present	Supports sessions and accounts
Billing models are present	Supports subscriptions and invoices
Ownership checks exist	Protects user data
Plan checks are server-verifiable	Prevents client-only access control
Webhook events are tracked	Reduces duplicate processing risk
Environment-specific data is separated	Avoids mixing test and production

Backend principle

If a rule affects money, identity, or private data, it should not live only in the frontend.

Delivery checklistLink to section

Use this if Starter Pro delivery or another paid digital product flow is active.

Check	Required behavior
Payment is confirmed by webhook	Access is not granted from redirect alone
Download asset is private	No permanent public file URL
Delivery token exists	Access can be controlled
Token expires	Shared links have limited value
Unauthorized access is rejected	Non-buyers cannot download
Expired token path is handled	Buyer has a recovery path
Confirmation copy is clear	Buyer knows what happens next

Go / no-go decisionLink to section

Ready to launch when

auth flows pass end-to-end
billing webhooks sync state correctly
protected routes enforce access
database migrations are stable
delivery is secure and tested

Do not launch if

checkout works but webhooks are untested
access is granted from client state only
reset password or verification flows are broken
production secrets are incomplete
paid files are publicly exposed

Common mistakesLink to section

Final pre-launch sequenceLink to section

Before launching, run through this final sequence:

deploy to preview
run auth flows
run Stripe test checkout
verify webhook events
confirm database updates
confirm paid access state
test protected routes
test delivery access
review production environment variables
deploy production
run one final smoke test

Launch with confidence

A strong launch is not just a clean UI. It is a product where identity, revenue, data, and access behave correctly together.

Next stepsLink to section

Auth system

Review authentication, sessions, providers, and account lifecycle.

Billing system

Validate Checkout, portal, webhooks, invoices, and subscription state.

Backend foundations

Validate database, ownership, access rules, and server-side boundaries.

Secure delivery

Validate post-purchase access, tokens, private storage, and fulfillment.