SaaS MVP Checklist: 23 Things You Must Do Before Launch

I built a 138,000-line TypeScript SaaS in 6 days that went to production. Not because I skipped these steps, but because I had a practiced checklist and executed it in the right order. Skipping any of these items means paying for it later at the worst possible time: when a paying customer hits the problem.

This list is opinionated. I am telling you specific tools because "use some analytics tool" is not useful advice. You can swap the tools; the categories are non-negotiable.

Authentication (Items 1–4)

1. Social OAuth with at least two providers

Tool: Firebase Auth, Clerk, or Auth.js. Email/password alone creates friction that kills conversions. At minimum, add Google OAuth. Add Apple if you are targeting iOS users. The incremental work is an hour; the conversion impact is real. Every additional click in your auth flow loses users.

2. Email verification before accessing paid features

Tool: your auth provider + Resend. Do not let unverified email addresses access anything you care about. Unverified accounts generate junk data in your analytics, can abuse free tiers, and inflate your user counts in misleading ways. Gate activation on a verified email.

3. Session expiry and refresh token handling

Built into Firebase Auth and Clerk. If you roll your own JWT, you need explicit refresh token logic and a graceful session expiry flow. "Your session has expired. Please log in again." is better than silently failing API calls and leaving the user staring at a broken page.

4. Route protection via middleware

Next.js middleware + auth provider SDK. Every protected route must redirect unauthenticated users consistently. Do not rely on individual page-level checks. One missed check in a component means a logged-out user can reach content they should not. Middleware runs before any page renders, making it the only reliable protection layer.

Payments (Items 5–8)

5. Stripe integration with webhook verification

Tool: Stripe. Stripe is the default choice for a reason: it handles PCI compliance, international cards, and tax handling better than any alternative. Do not skip webhook signature verification. Without it, any server can post a fake payment event to your endpoint and unlock paid features for free.

6. Subscription state stored in your database, not just Stripe

Firestore or Postgres field: subscription.status. Your app logic should never call the Stripe API on every request to check if a user is paying. Cache subscription status in your own database, updated by webhooks. This eliminates a latency hit and a rate-limit dependency on every page load.

7. Failed payment handling and dunning email

Tool: Stripe Billing + Resend. Cards expire. Payments fail. You need an automated email sequence that notifies users of failed payments and gives them a clear path to update their card. Stripe's Smart Retries handles the retry logic; you handle the email communication. Passive churn from failed payments is silent and expensive.

8. A working test mode end-to-end

Stripe test cards (4242 4242 4242 4242). Before launch, complete the full payment flow in test mode from a fresh account with no developer access. Check that the webhook fires, the subscription status updates in your database, and the user is redirected to the correct post-payment state. Do this again after every deploy that touches payment logic.

Error Handling (Items 9–11)

9. Global error boundaries in React

React ErrorBoundary component at the route level. Without error boundaries, a single thrown exception in a component crashes the entire page and shows the user a white screen with no context. A properly implemented error boundary catches the error, shows a fallback UI, and lets the user recover without a full page reload.

10. API error response format standardized

Consistent JSON error schema: code, message, status. Every API route should return errors in the same format. Inconsistent error shapes mean your frontend has to handle five different error patterns, and logging becomes difficult because every error looks different. Pick a format before you write your first route and enforce it everywhere.

11. User-facing error messages that are not stack traces

This sounds obvious but is regularly violated. "TypeError: Cannot read properties of undefined (reading 'map')" is not an acceptable error message for a paying user. Map your internal error codes to human-readable messages before launch. If you use Sentry or similar, configure it to strip sensitive data from error reports before they are transmitted.

Monitoring (Items 12–14)

12. Error tracking in production

Tool: Sentry (free tier covers most MVPs). Without error tracking, you find out about production bugs when users email you or leave negative reviews. With Sentry, you know within minutes, you have a stack trace, you have the user's browser and OS, and you have the sequence of actions that led to the error. This is table stakes for anything with real users.

13. Uptime monitoring with alerting

Tool: Better Uptime or UptimeRobot (both have free tiers). Your app will go down. A deploy will fail. A third-party API will have an outage. You need to know within two minutes, not two hours when users start complaining. Set up a check on your homepage and your most critical API endpoint. Configure SMS or Slack alerts.

14. Performance monitoring for your slowest pages

Tool: Vercel Analytics or Next.js built-in Web Vitals. Pages that take more than 3 seconds to load lose users before they engage. Identify your slowest routes before launch and fix the obvious problems: unoptimized images, blocking data fetches on the client, missing caching headers.

Analytics (Items 15–16)

15. Product analytics with event tracking

Tool: PostHog (open source, generous free tier) or Mixpanel. Pageviews tell you who visited. Event tracking tells you what they did. Before launch, instrument your core user flow: sign up, complete onboarding, activate core feature, reach paywall, convert. Without this, you are flying blind when you need to improve conversion rates.

16. Funnel analysis set up before you have traffic

Create your conversion funnel in your analytics tool before launch, not after. If you set it up retrospectively, you lose historical data. The funnel from landing page visit to paid subscriber is the most important dashboard you have; it should be ready the moment your first user signs up.

Legal (Items 17–18)

17. Privacy Policy and Terms of Service pages

Tool: Termly or Iubenda for generation; link in footer. You need both before you collect any user data. This is not optional. Stripe requires Terms of Service for payment processing. App stores require Privacy Policy for any app that collects user information. GDPR and CCPA require disclosure of data practices. Spend $30 on a generator, not $5,000 on a lawyer, for your first version.

18. Cookie consent for EU users

Tool: Cookieyes (free tier covers MVPs). If you use any analytics, you set cookies, and GDPR requires consent for EU users. The fines are not hypothetical. This takes 30 minutes to implement. Skip it and you have legal exposure from day one.

Email (Items 19–21)

19. Transactional email on a verified domain

Tool: Resend + your own domain. Do not send transactional email from Gmail or an unverified domain. Set up SPF, DKIM, and DMARC records. Emails from unverified domains land in spam, which means your password reset emails do not arrive, your welcome emails do not arrive, and your trial expiry notices do not arrive. This is a five-minute DNS configuration.

20. Welcome email sent immediately on sign up

The moment a user creates an account is when your product has the most of their attention. A welcome email sent within 60 seconds that tells them the one thing to do first increases activation rates. This does not need to be a marketing sequence; it needs to be a single, clear next step. Send it immediately, not via a 24-hour batch job.

21. Trial expiry notification sequence

If you have a free trial, send emails at 7 days before expiry, 3 days before, and the day of. Each email should have a single clear call to action: upgrade. Users who do not receive these emails convert at a fraction of the rate of users who do. This is the highest-ROI email you will ever send.

Onboarding (Items 22–23)

22. A defined activation event

What is the one action a user takes that correlates with them sticking around? For a project management tool, it might be creating and sharing their first project. For a CRM, it might be importing contacts. You need to define this before launch, instrument it as an event, and design your onboarding flow to drive users toward it as quickly as possible.

23. An empty state that is not just empty

Every part of your product that a new user sees before they have data needs an empty state that guides them to add that data. A blank dashboard with no guidance creates confusion and abandonment. The empty state should show what the filled state looks like and provide one clear action to get there. This is the single cheapest improvement you can make to activation rates.

The order matters

Do not build these in the order I listed them. Auth first, then error handling, then payments, then monitoring. Legal and email can run in parallel with payments. Onboarding is the last thing you build but the first thing a user experiences, so give it more time than you think it deserves.

The mistake most founders make is treating launch preparation as a second-class citizen after the core feature. The core feature gets you to demo day. Everything on this list determines whether the users from demo day stick around and pay.