Articles

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 ~EUR 5/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.

  • 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.

7a9a8821

© 2026 Stacknaut