Pre-launch checklist: 30 things to ship before your SaaS hits paid users

If you're a B2B SaaS founder about to launch a paid product, the difference between a clean launch and a long fire drill is usually 30 specific items that get shipped (or skipped) in the final week before launch. Most of them aren't in your product demo. None of them sound exciting in a pitch deck. All of them prevent specific incidents that cost real money once customers are paying.

This piece is the 30-item pre-launch checklist we use on B2B SaaS builds. It is organized in six categories. Print it; check each item before you flip the switch on the first paying customer.

#Auth + billing (8 items)

The category most likely to break in production with paying customers.

#1. Auth flow tested across 5 browsers + mobile

Sign up, log in, password reset, OAuth, and magic links work on Chrome, Safari, Firefox, Edge, and at least one mobile browser. Edge cases: third-party cookie restrictions, Safari intelligent tracking prevention, slow-network email delivery for password reset.

#2. Stripe live mode wired correctly

Customer creation, subscription creation, plan switching, cancellation flow all working against Stripe live mode (not just test mode). Test with a real $1 charge to your own card.

#3. Stripe webhook handler hardened

Idempotent (handles duplicate events), signature-verified, has a dead-letter queue for unprocessable events, audit log of every event received and what your system did with it. For the deep dive, see Auth + billing for SaaS MVPs.

#4. Card-expired flow handled

When a customer's card expires mid-subscription, your system should: send a "your payment failed" email, retry the charge after the standard Stripe dunning period, eventually downgrade or cancel if all retries fail. Test this with a Stripe test card.

#5. Disputed-charge flow handled

When a customer disputes a charge (chargeback), your system should: receive the charge.disputed webhook, log it, optionally notify your team, update the customer's account state if you lose the dispute. It is easy to skip this and discover it after the first chargeback.

#6. Refund flow operational

If a customer asks for a refund, you can issue it through the Stripe dashboard (or your admin panel) and the customer's account state updates correctly. The money-back guarantee is operationally simple if this is wired; chaotic if it isn't.

#7. Tax handling configured

Stripe Tax enabled with the right product categories, customer-creation flow captures the tax-relevant fields (billing address, EU VAT ID, with a rule for what happens when Stripe's verification of it fails, US exemption certificates where they apply). For the deep dive, see Stripe Tax for SaaS.

#8. Plan-switching flow tested

A customer can upgrade, downgrade, swap plans through your UI; Stripe prorates correctly; the customer's feature access updates correctly. Test all four directions (upgrade, downgrade, switch annual to monthly, switch monthly to annual).

#Security (6 items)

The category most likely to come back to bite you later.

#9. Rate limits on every public endpoint

Every endpoint that accepts requests from unauthenticated users (signup, login, password reset, contact form, public API) needs rate limits. A reasonable starting point: 10 requests per minute per IP, 100 per hour. Tune it to your traffic. Implement via Vercel rate limit or an equivalent middleware.

#10. Input sanitization

All user input that lands in HTML (rendered in another user's browser) is properly escaped. Frameworks like Next.js handle most of this by default; verify by injecting a <script>alert('xss')</script> payload into every form field and confirming it renders as text.

#11. SQL injection protection

You're using parameterized queries (Drizzle, Prisma, or any reasonable ORM handles this). No string concatenation into SQL queries. Test with '; DROP TABLE users; -- payloads in form fields, against a staging database, to confirm.

#12. SSL hygiene

HSTS header set, secure cookies (Secure + HttpOnly + SameSite=Lax), CSP header defined, no mixed content. Validate at SSL Labs; aim for an A or A+ rating.

#13. Secrets rotation check

API keys, database credentials, third-party tokens are stored in environment variables (not code). You have a documented procedure for rotating each. Test rotating one secret end-to-end without downtime.

#14. RLS or equivalent on the database

Row-level security on Postgres, or equivalent application-level access control. A user can only read/write rows they own. Test with a second user account trying to access the first user's resources.

#Performance (4 items)

#15. Lighthouse 90+ on marketing pages

Run Google's Lighthouse against your marketing homepage, pricing page, and any landing page. Score 90+ on Performance, Accessibility, SEO. App pages can be lower (interactive surfaces are different); marketing pages are not negotiable.

#16. Database query plans on heavy reads

The 5 most-frequent database queries have indexes that match their access patterns. Run EXPLAIN ANALYZE on each; verify no sequential scans on tables over 10k rows. The fix is usually a few indexes added in a migration.

#17. Image optimization

User-uploaded images are resized and compressed before serving. Static marketing images use Next.js Image or equivalent. No 5MB hero images shipped uncompressed.

#18. CDN cache configuration

Static assets (CSS, JS, images, fonts) have appropriate cache headers (1 year for hashed assets, no-cache for HTML). Verify with curl -I against your production assets.

#Monitoring + ops (5 items)

#19. Error monitoring wired

Sentry (or equivalent) installed with source maps uploaded so stack traces are useful. Errors aggregate by similarity; alerts fire to Slack on new errors above a threshold. Test by intentionally throwing an error and verifying the alert.

#20. Uptime monitoring

A third-party service (Better Uptime, Pingdom, or equivalent) checks your homepage every 60 seconds and alerts on downtime. Status page (publicly accessible) recommended for B2B SaaS.

#21. Production deploy rollback procedure

Documented and tested. You can revert a bad deploy in under 5 minutes (Vercel makes this a one-click operation; verify it works before you need it). The rollback should preserve in-flight requests and not break user sessions.

#22. Database backup verification

Daily backups configured (managed Postgres hosts such as Supabase, Neon and RDS offer backups or point-in-time restore; check what your plan includes). You've tested restoring a backup to a staging environment within the last 30 days. Untested backups are theoretical backups.

#23. Audit log of admin actions

Every action your operations team takes through the admin panel (impersonate user, refund, cancel subscription, edit user data) is logged with timestamp, actor, action, target. Critical for compliance and for debugging "what did Bob do that broke this customer's account."

#Content + UX (4 items)

#24. Every empty state has copy

Every screen in your product that can be empty (no users yet, no projects yet, no notifications yet) has a useful empty state. Not just "No items." A useful prompt that tells the user what to do next.

#25. Every error message is human-readable

No "Error: 500 Internal Server Error" surfaced to users. Every error message says what happened in plain language and what the user can do about it. Test by intentionally triggering errors (network timeout, invalid input, rate limit hit) and checking the user-facing message.

#26. Email templates are branded

Welcome email, password reset, billing receipt, payment failed, etc. all look like they came from your product, not from Stripe defaults or Clerk defaults. Brand colors, your logo, your sender email, your support contact.

#27. Onboarding flow tested with real users

3 to 5 friendly users have walked through the signup → first-action flow without your help. Note where they got stuck. Fix the top 3 friction points before launch.

#Legal + compliance (3 items)

This section is general information, not legal advice.

#28. Privacy policy matches actual data practices

What data you collect, how you use it, who you share it with, how users can request deletion. The policy must accurately describe what your code does. Mismatches between the policy and the code can create legal exposure.

Termly, Iubenda, or your lawyer can generate the policy; you have to verify it matches reality.

#29. Terms of service shipped

Drafted, reviewed by a lawyer (or at least informed by templates from TermsFeed or equivalent), accepted by users on signup with a checkbox + timestamp logged.

#30. GDPR-relevant data handling

If you have any EU users (you likely will), you will generally need: a privacy policy that's GDPR-compliant, a way for users to request data deletion, a way for users to export their data, a list of data processors (Stripe, Vercel, Sentry, etc.) maintained as part of your privacy posture. For GDPR specifics, read a dedicated reference and confirm the details with a lawyer.

#How to actually ship this

The 30-item checklist isn't a "ship a feature" exercise; it's roughly a 5-to-7-day operational hardening pass. A sensible sequencing within a six-week build:

• Week 5 of the build: Items 1 to 8 (auth + billing), 19 to 23 (monitoring + ops). The team is already in Stripe + admin code; tackle the operational items in the same context.
• Week 6, days 26 to 28: Items 9 to 18 (security + performance). These are the audit-style items that are easier to do in a focused sprint than scattered across the build.
• Week 6, day 29: Items 24 to 27 (content + UX). The polish pass that turns the product from "functional" to "shippable."
• Week 6, day 30: Items 28 to 30 (legal + compliance). The last items, often the items the founder handles personally with their lawyer.

For the broader week-by-week build context, see SaaS MVP timeline: a realistic week-by-week build plan.

#How we approach it

When we build an MVP, we work through this checklist before launch and review it with the founder before the first paying customer is switched on.

Five items tend to get questioned as "do we really need this for v1": #5 (disputed-charge flow), #14 (RLS on database), #21 (rollback procedure tested), #29 (lawyer-reviewed terms), #30 (GDPR data handling). Each is cheaper to handle before launch than after an incident, so they stay on the list.

For how the build itself is structured, see MVP Development.

#Bottom line

The 30-item pre-launch checklist is the gap between "we built a working product" and "we built a product we can charge paying customers for." Teams often launch with several items missing; the missing items tend to become production incidents that cost more to fix under fire than they would have to ship correctly.

Print the list. Check each item before launch. The days of focused work on the checklist can save far more time in incident response after launch.

The checklist belongs to the final two weeks of a build; the discipline is what makes the launch clean. If you'd like help getting a product launch-ready, our MVP development is fixed-price, from $9,800, and every build includes a 30-day fix window after launch. To talk it through, book a free 20-minute call.

Common questions.

• Is this checklist for v1 launch or for general production readiness?

  Both. The 30 items are the minimum bar for launching a paying B2B SaaS product to actual customers. v1 includes all 30; production readiness for v2 and beyond is an expansion of the same categories. If you can't check 25+ of the items, you're shipping a prototype with the 'production' label, and the gap tends to become your incident backlog after launch.

• What if I'm shipping a free tier first, no paid users yet?

  About 20 of the 30 items still apply (auth, security, monitoring, content, legal). The other 10 (billing, refund flow, dunning, tax, etc.) only matter when paid users exist. The framing shifts from 'pre-launch' to 'pre-paid-launch'; ship the 20, defer the 10 until paying customers are imminent.

• Which 5 items are easiest to miss?

  (1) Hardened Stripe webhook handler with retry + dead-letter queue, (2) production deploy rollback procedure documented and tested, (3) error monitoring with alerts wired to Slack, (4) SSL hygiene check (HSTS, secure cookies, CSP headers), (5) GDPR/privacy policy that matches actual data practices. These five items don't show up in product demos, which makes them easy to skip and painful when they fail.

• How long does this checklist take to ship?

  If done alongside the build (for example, in the last two weeks of a six-week build), roughly 5 to 7 days of focused work. If left until after the rest of the build is done, it usually takes longer, because each item depends on context the team has already moved past. Build the checklist into the final weeks, not after them.