The SaaS Launch Checklist I Wish I Had

Every time I launch a SaaS, I forget something. A DNS record, a webhook endpoint, a missing error page. Then I'm fixing it while real users are signing up.

This is the checklist I use now. I'm assuming you've built the thing and you're ready to put it in front of people — not a "how to validate your idea" list.

Infrastructure

If you're on a managed platform like Vercel, Render, or Heroku, most of this is handled for you — skip to DNS and monitoring. If you're running your own server:

• Server provisioned and hardened (firewall, fail2ban, SSH key-only access)
• DNS records pointing to your server (A records for all subdomains)
• SSL certificates working (test with curl -vI https://yourdomain.com)
• HTTPS enforced — HTTP redirects to HTTPS
• Database backups configured and tested — actually restore one to verify
• Health check endpoints responding (/health on each service)
• Log collection set up and flowing to a dashboard you'll actually check
• Error tracking configured (Sentry, BetterStack, or similar)
• Server monitoring with alerts — CPU, disk, memory

A single server is all you need to launch — and probably all you need for a long time after that. Just make sure you know what your recovery plan is if it dies. A Terraform config that can reprovision everything in minutes is worth more than a complex multi-server setup you don't understand.

I use Hetzner for hosting (a CPX11 at ~$10/month runs multiple SaaS products), Terraform to provision the server, and Kamal 2 for zero-downtime deploys.

Authentication

• Login flow works end-to-end (magic link, Google Sign-In, or whatever you're using)
• If using password auth: passwords are salted and hashed (bcrypt or argon2 — never store plaintext or unsalted hashes)
• Email delivery tested from production (not just dev). Check spam folders
• Session expiry and refresh working correctly
• Cookies set with secure, httpOnly, and sameSite flags
• Logout actually clears everything — tokens, cookies, local storage
• Password reset or re-authentication flow works (if applicable)
• Users can only access their own data — verify API endpoints enforce ownership checks
• Rate limiting on auth endpoints to prevent brute force
• Test the flow in incognito mode on both desktop and mobile

I recommend Google Sign-In, optionally with magic link as a fallback. No passwords to store, no reset flows to build, no credential stuffing to worry about.

The most common launch-day bug I've seen: emails landing in spam. Send test emails from your production domain to Gmail, Outlook, and Hey. Check your SPF, DKIM, and DMARC records. This is not optional.

Billing

• Stripe (or your payment provider) in live mode, not test mode
• Webhook endpoint configured and receiving events in production
• Test a real purchase with a real card (Stripe has a $0.50 minimum)
• Subscription lifecycle works: create, renew, cancel, resubscribe
• Billing portal accessible for customers to manage their subscription
• Receipts/invoices being sent
• Handle payment failures gracefully — show the user a clear message, don't just crash
• Webhook handlers are idempotent — Stripe will retry, and your handler should handle duplicates
• Cancellation flow is clear and doesn't require contacting support
• Know how you'll handle refund requests (Stripe makes this easy from the dashboard)

Test the entire payment flow yourself. Use a real card. If you're uncomfortable charging yourself $10 to verify your billing works, you're not ready to charge customers.

I use Stripe. The webhook handling is the part most people get wrong — test the full lifecycle, not just the happy path.

Legal and Compliance

• Privacy policy published and linked from signup flow
• Terms of service published
• Contact email visible and working

You don't need a lawyer for v1. Use a generator, read through it, and make sure it's accurate. But do have one.

SEO and Discoverability

• Page titles and meta descriptions set for every public page
• Open Graph tags working (test with MyOG)
• Sitemap.xml submitted to Google Search Console
• Canonical URLs set to prevent duplicate content
• robots.txt allows crawling of public pages
• 404 page exists and doesn't return a 200 status code
• Page load time under 3 seconds on mobile (test with PageSpeed Insights)
• Pre-render or SSR for public pages that need to be indexed

Email

• Transactional email provider configured (Postmark, SES, Resend)
• Sender domain verified with SPF, DKIM, and DMARC
• Welcome email sent on signup
• All transactional emails tested from production
• Unsubscribe link in any marketing emails
• Reply-to address goes somewhere you'll actually read
• Cap outbound messages per user (email, Telegram, SMS) — a bug in a retry loop shouldn't send 500 emails to the same person

I use Postmark. Reliable deliverability, good logs, and simple API.

Error Handling and Edge Cases

Your backend should never trust the frontend. Anyone can open a terminal and curl your API with whatever payload they want. Every check that matters — authentication, authorization, input validation, rate limits, usage caps — must be enforced server-side. Frontend validation is a UX convenience, not a security boundary.

• What happens when the database is down? (Don't show a stack trace)
• What happens when a third-party API times out?
• Rate limiting on public API endpoints
• Input validation on all user-facing forms
• File upload size limits if you accept uploads
• CORS configured correctly for your domains

Spending Controls

• Set spending caps or budget alerts on AI APIs (OpenAI, Anthropic, etc.)
• Set billing alerts on cloud providers (AWS, GCP, Hetzner)
• Set spending limits on email providers if usage-based (SES, Postmark)
• Rate limit your own API endpoints that call paid services — one runaway user shouldn't blow your budget
• Backend endpoints that incur monetary cost (AI APIs, SMS, etc.) must enforce rate limits server-side, even if the frontend also limits usage. Frontend limits are trivial to bypass

Monitoring and Observability

• Uptime monitoring with alerts (UptimeRobot, BetterStack, or similar)
• Error alerting — you should know about 500s before your users tell you
• Structured logging — use JSON logs with request IDs, timestamps, and user context. When something breaks at 2am, grep through unstructured text is not fun
• Never log sensitive data (passwords, tokens, full credit card numbers, API keys)
• Key business metrics visible: signups, conversions, active users
• Stripe webhook failures monitored (Stripe dashboard shows these)
• Log retention long enough to debug issues (at least 7 days)

Set up analytics before launch, not after — you'll lose day-one data otherwise. Set up session replay too. When a user reports "it doesn't work," you can watch exactly what happened instead of guessing. I use PostHog for session replay and product analytics, and BetterStack for uptime monitoring and log collection.

Pre-Launch Smoke Test

Do this on your production environment, not staging:

• Sign up as a new user
• Complete the core user journey (whatever your app's main flow is)
• Make a purchase
• Cancel the subscription
• Log out and log back in
• Try the app on mobile
• Try the app in Safari (it's always Safari)
• Hit a non-existent URL and verify the 404 page
• Check that no debug logs or stack traces leak to the browser console
• Remove any debug endpoints, test accounts, or admin backdoors from production

Launch Day

• Remove any "coming soon" or placeholder content
• Verify all external links work (pricing page, docs, social links)
• Have a way to communicate with early users (email, Discord, Twitter DMs)
• Know how to deploy a hotfix quickly (you will need to)
• DNS TTL lowered before launch (in case you need to switch servers)
• Tell people. Seriously. The biggest launch mistake is not telling enough people

After Launch

Things to do in the first week:

• Watch your error logs daily
• Respond to every support email within a few hours
• Track where your signups are coming from
• Fix the top 3 friction points users hit
• Write down what broke and what you forgot — update this checklist for next time

The Only Checklist Item That Matters

Ship it. Half of the items above can be fixed in the first week. The ones that can't — billing, auth, SSL — are the ones to get right before launch. Everything else is iterative.

I've seen too many projects die in "almost ready" mode. Pick a date, work backward from this list, and launch.

Once you're live, check out the Post-Launch Hardening Checklist for everything you should tighten up in the weeks after launch.