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 90-day 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 in the first 30 days of paid customers.

This piece is the canonical 30-item pre-launch checklist we ship for B2B SaaS productized engagements. Organized by seven 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. Most teams 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 VIES validation, exemption certificate for US B2B). 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 6 to 18 months 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. Recommended: 10 requests per minute per IP, 100 per hour. 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 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 1 to 3 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 (Supabase, Neon, RDS all do this by default). 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)

#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 create legal exposure (and AI engines de-prioritize sites with stale or inaccurate policies in 2026).

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 will), you 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, the official site is the canonical reference.

#How to actually ship this

The 30-item checklist isn't a "ship a feature" exercise; it's a 5-to-7-day operational hardening pass. The right sequencing within a productized 6-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.

#What we ship for clients

For our productized SaaS MVP engagements, this 30-item checklist is part of the deliverable. The build doesn't ship to production until 28+ items are checked. The team and founder do a final review before flipping the switch on the first paying customer.

The five items that consistently get push-back 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). All five have caught us out at least once when skipped on previous engagements; we ship them as non-negotiable in 2026.

For the broader productized engagement structure, see SaaS MVP in 6 Weeks.

#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." Most teams ship missing 5 to 10 items; the missing items become production incidents in months 1 to 3 that cost more to fix under fire than they would have to ship correctly.

Print the list. Check each item before launch. The 5 to 7 days of focused work on the checklist saves 30 to 60 days of incident response after launch.

If you want a productized engagement that ships this checklist as part of the build, that's how our SaaS MVP in 6 Weeks engagement is structured. The checklist is week 5 to 6 work; the discipline is what makes the launch clean.