The Production SaaS Launch Checklist

This SaaS launch checklist covers the technical side of going live: 42 checks to run before real users and real payments reach your app. Work through it in order the week before launch, and again before any major release. Each item is a failure that has cost founders customers or money in production.

Authentication & Access

• Sessions survive a deploy, with no forced logout when you ship new code
• OAuth redirect URLs are registered for both localhost and your production domain
• Password reset and magic link emails land in the inbox, not spam (SPF/DKIM configured)
• Every protected route checks auth server-side, not just in client-side UI state
• Rate limiting is in place on login, signup, and password reset endpoints
• Session tokens are invalidated on password change and account deletion
• Row Level Security policies are enabled on every table containing user data, not just the obvious ones

Payments & Billing

• Stripe webhook signature verification is enabled; never trust unsigned webhook payloads
• Webhook handling is idempotent, so a retried event doesn't double-charge or duplicate an order (only 3 of 14 open-source starters do this; see our audit)
• Failed payments and disputes have a defined recovery flow, not just a Slack ping
• Test mode and live mode keys are not mixed across environments
• Refunds and cancellations update your own database, not just Stripe's dashboard
• Tax handling (Stripe Tax or manual) is decided before your first sale, not after
• Pricing page and Checkout Session line items always match, with no silent drift

Security Checks Before Launch

• All secrets (API keys, service role keys) live in environment variables, never in git history
• Content-Security-Policy headers are set and don't rely on unsafe-eval
• Every API route validates and sanitizes input, not just the ones you remember are risky
• Dependency vulnerabilities are scanned automatically (npm audit, Dependabot, or similar) on every PR
• CORS is scoped to your actual domain, not left wide open with a wildcard
• Admin and internal routes require explicit authorization checks, not just being "hard to guess"
• A security incident response plan exists before you need one

Data, Privacy & Legal

• A privacy policy and terms of service are published and linked from every page that collects data
• Users can export their own data on request (GDPR Article 15 / CCPA)
• Users can delete their account and data on request (GDPR Article 17), with retention exceptions documented
• Cookie consent is implemented if you use non-essential tracking cookies
• Database backups run automatically and you've actually tested a restore
• PII is never logged in plaintext (application logs, error trackers, analytics)
• A data processing agreement exists with every third-party vendor that touches user data

SEO & Discoverability

• Every page has a unique title tag and meta description, with no duplicates across the site
• sitemap.xml exists, is submitted to Search Console, and matches your actual routes
• robots.txt doesn't accidentally block pages you want indexed
• Structured data (JSON-LD) validates without errors in Google's Rich Results Test
• Canonical URLs are set to prevent duplicate-content penalties from URL variants
• Core Web Vitals (LCP, CLS, INP) pass on mobile, not just desktop
• Open Graph and Twitter Card images are set so shared links don't look broken

Performance, Deployment & Monitoring

• Error tracking (Sentry or similar) is wired up before launch, not after the first user complaint
• A staging environment exists and mirrors production closely enough to catch real bugs
• Rollback is a single command, not a multi-step manual recovery
• Database migrations are reversible or have a documented rollback path
• Uptime monitoring pings your app and actually alerts a human, not just a dashboard nobody watches
• Rate limits and timeouts are set on every external API call, so one slow vendor can't take you down
• You've load-tested at least once at 5-10x your expected launch traffic

What this checklist doesn't cover

This list stops at "the product is safe to put in front of people". It doesn't cover marketing a launch (positioning, launch channels, announcements). For the build itself, from choosing a stack through billing, database design and deployment, read How to Launch a SaaS in 2026.