SaaS Launch Checklist: 25 Checks Before Production

A SaaS launch checklist protects you from the failures that a polished homepage cannot reveal: a webhook pointed at localhost, an unverified email domain, a backup nobody has restored, or a paid account that still sees “Free.” The goal is not perfection. It is a controlled V1 where customers can sign up, pay, receive value, recover from mistakes, and contact a human.

This checklist is for founders and small teams preparing to accept their first production payment. It contains 25 concrete checks organized by launch risk.

The 25-point checklist at a glance

Product and customer journey

• 1. The production value proposition, price, and CTA agree everywhere.
• 2. A new customer can reach value without founder intervention.
• 3. Empty, loading, error, and permission-denied states are understandable.
• 4. Support and refund routes are visible before purchase.

Identity and security

• 5. Email verification and password reset work on the production domain.
• 6. OAuth callback URLs use production HTTPS URLs.
• 7. Every sensitive server mutation checks authorization itself.
• 8. Login, checkout, and public forms are rate-limited.
• 9. Production secrets are unique, strong, and stored outside Git.

Money and fulfillment

• 10. Stripe uses live keys and a live webhook endpoint.
• 11. Webhook signatures and idempotency are tested.
• 12. Tax, receipts, refunds, and delayed payment methods have explicit policies.
• 13. A real purchase grants the correct entitlement exactly once.

Data and infrastructure

• 14. Production migrations run as a controlled deployment step.
• 15. Automated database backups exist and one restore has been tested.
• 16. Private uploads and downloads work from the production origin.
• 17. Health checks and uptime alerts cover the application and database.
• 18. Error tracking receives readable production stack traces.

Legal, email, and trust

• 19. Privacy and terms pages describe the real business and providers.
• 20. The sending domain has SPF, DKIM, and DMARC configured.
• 21. Transactional emails contain production links and a monitored reply path.

Discovery and release operations

• 22. Titles, descriptions, canonical URLs, sitemap, robots, and OG images are correct.
• 23. Analytics and consent behavior match the privacy policy.
• 24. CI, browser tests, and a production-like smoke test are green.
• 25. The team has a rollback plan and a launch-day owner.

Product and customer journey checks

1. Align the promise, price, and CTA

Search the landing page, pricing page, navigation, FAQs, emails, and checkout description for old prices or claims. A $99 lifetime offer should never become $149 in one forgotten card. State what buyers receive today, what “future kits” means, and whether access depends on keeping an account.

2. Test the first-value path

Create a completely new user without database shortcuts. Verify the email, sign in, pay, find the download, and open the delivered artifact. Record the time and every moment where the next action is unclear.

3. Review non-happy states

Test an empty downloads page, expired link, duplicate purchase, failed upload, unavailable database, invalid invitation, and unauthorized admin URL. Error copy should tell the customer what happened and what they can do next without leaking implementation details.

4. Make support and refunds discoverable

Put a working contact route in the footer and near the purchase decision. Decide who monitors it, expected response time, and how refunds are approved and recorded. A policy no one can execute is not a policy.

Identity and security checks

5. Exercise account recovery in production

Verification and reset emails often pass locally but fail after deployment because their base URL or sender domain is wrong. Follow each production email link in a private browser window and verify expiry behavior.

6. Replace every development callback

Update the authentication base URL and Google OAuth authorized redirect URI to the exact HTTPS production origin. Decide whether www redirects to the apex domain or the reverse, then use the canonical origin consistently.

7. Verify authorization at the mutation

Middleware redirects improve UX but do not secure a Server Action or API route by themselves. The OWASP Authorization Cheat Sheet recommends deny-by-default access and permission validation on every request.

8. Rate-limit abuse targets

Protect sign-in, signup, password reset, contact, checkout creation, invitations, and expensive API calls. Confirm the client IP source is trustworthy behind your chosen proxy or CDN.

9. Rotate and isolate production secrets

Generate a new authentication secret, use provider-specific production credentials, restrict storage keys to the required bucket, and keep secrets in the deployment platform. Do not promote a development .env file into production.

Money and fulfillment checks

10. Switch the entire Stripe chain to live mode

A live secret key is not enough. Create or verify the live webhook endpoint, copy its live signing secret, configure tax settings, review branding and support details, and confirm the success and cancel URLs use the production domain.

11. Prove webhook authenticity and idempotency

Reject invalid signatures and replay a successful event. The second delivery must not send a second email or create a second entitlement. Stripe's webhook guide documents signature verification, retries, and event-delivery behavior.

12. Decide tax and refund behavior

Document whether prices include tax, which entity handles remittance, what qualifies for a refund, and what happens to download access after one. If delayed payment methods are enabled, do not fulfill until payment is actually paid.

13. Run one real end-to-end purchase

Use a real non-admin customer and a live payment method. Verify the amount, tax, receipt, webhook status, database purchase, dashboard entitlement, confirmation email, and private download. Then refund it and confirm your operational process.

For implementation details, use the guide to Stripe one-time payments in Next.js.

Data and infrastructure checks

14. Make migrations explicit

Know whether migrations run before traffic shifts, during container startup, or in a separate release job. Ensure two application instances cannot race the same unsafe migration.

15. Restore a backup

Confirm backup frequency, retention, encryption, and region. Restore the latest backup into an isolated database and run a small integrity check. A backup is an assumption until a restore succeeds.

16. Test storage from the production origin

Object storage CORS rules must include the exact production origin, without a path or trailing slash. Upload a real release, verify its size, download it as an entitled customer, and confirm an unentitled customer receives no signed URL.

17. Monitor health and uptime

Expose a health endpoint that checks critical dependencies and configure an external monitor from a different network. Alert a person through a channel they actually watch.

18. Verify production error tracking

Trigger one controlled client error and one server error. Confirm source maps produce readable stack traces, environment tags distinguish production from staging, and sensitive customer data is not attached unexpectedly.

Legal, email, and trust checks

19. Replace legal placeholders

Your privacy policy should describe the data you collect, purposes, processors, retention, customer rights, contact details, and applicable jurisdiction. Your terms should cover the license, prohibited redistribution, payments, refunds, warranties, liability, termination, and governing law. Have qualified counsel review them for your situation.

20. Authenticate the sending domain

Configure SPF and DKIM with the email provider, add a DMARC policy, and test delivery to major inbox providers. Avoid shipping production mail from a shared onboarding address.

21. Inspect every transactional email

Verify sender name, reply-to address, logo, subject, production links, mobile rendering, and plain-text meaning. Test verification, reset, welcome, purchase confirmation, invitation, and account deletion messages.

Discovery and release-operation checks

22. Crawl the public site

Every indexable page needs a unique title and description, a production canonical URL, and useful social-share metadata. Open /robots.txt and /sitemap.xml after deployment. Confirm authenticated, admin, and API pages are excluded. The Next.js production checklist includes metadata, Open Graph images, sitemaps, and robots among its production recommendations.

23. Align analytics and consent

If analytics is disabled, decide how you will measure acquisition and conversion. If enabled, confirm the consent banner controls the script and update the privacy policy with the actual provider and purpose.

24. Run production-like validation

Run lint, type checking, unit tests, database integration tests, browser tests, and a production build. Start the built output locally or in staging and repeat the critical smoke path. Use Lighthouse as a lab signal and monitor real Core Web Vitals after traffic arrives; web.dev's Core Web Vitals guide explains the current user-experience metrics.

25. Prepare rollback and ownership

Write down how to roll back application code, what happens if a migration is not reversible, who watches errors, who answers support, and what conditions pause the launch. Keep the first release small enough that one person can understand its operational state.

Frequently asked questions

What is the minimum SaaS launch checklist for a solo founder?

Prioritize five complete journeys: signup and recovery, live payment and fulfillment, backup and restore, error detection, and customer support. Add accurate legal pages and production-domain configuration before collecting personal data or money. Everything else can be prioritized by product risk and customer impact.

Should I launch without analytics?

You can launch without analytics, but you still need a measurement plan. Payment events, signup counts, support conversations, and customer interviews may be enough for an early V1. If you add analytics, ensure consent behavior and the privacy policy accurately describe the implementation.

Do I need a staging environment before V1?

Not always, but you need a production-like verification environment. A staging deployment is especially valuable when webhooks, OAuth callbacks, object-storage CORS, and deployment-specific headers differ from localhost. Keep staging isolated from live payments and production customer data.

When is a SaaS ready to launch?

A SaaS is ready when its core promise works end to end, money and permissions fail safely, data can be recovered, errors reach an operator, and customers have a support path. Readiness is evidence from tested workflows, not the absence of unfinished ideas.

Launch a controlled V1

This SaaS launch checklist is intentionally operational. Customers will forgive a small roadmap; they will not enjoy paying twice, losing access, receiving broken links, or discovering placeholder legal text.

If infrastructure is slowing down your product work, compare SaaS boilerplate vs building from scratch, inspect the Shipkitt Next.js starter, or review the $99 lifetime offer.