SaaS MVP Checklist: 47 Things to Verify Before You Launch

Why MVPs Fail After Launch

Most SaaS MVPs that fail post-launch do not fail because the product idea was wrong. They fail because the launch itself was wrong. The first paying customer triggers a payment failure webhook that was never handled. A user with admin privileges can access another tenant’s data because row-level security was assumed but never verified. The error tracking service was installed but never tested, so a production exception goes unnoticed for three days.

These are not edge cases. They are predictable failure modes that a checklist eliminates.

The relationship between a checklist and building is misunderstood. A checklist is not a substitute for knowing what you are doing — it is what competent people use to ensure they have not skipped a step they know matters. Aviation uses checklists. Surgery uses checklists. Not because pilots and surgeons are incompetent, but because the cost of a missed step is too high to trust memory under time pressure.

Your first paying customer is exactly that kind of high-stakes moment. Use the checklist.

This list covers 47 items across six areas. Not every item applies to every product — a simple single-user tool does not need the same multi-tenancy verification as a team-based B2B platform. Use judgment. But if you are skipping an item, be deliberate about why, not just because you ran out of time.

For context on what a well-scoped MVP looks like and what it costs to build one correctly, our complete SaaS MVP development guide covers the architecture decisions and feature scope that precede this checklist.

---

Section 1: Architecture & Infrastructure

Multi-tenancy isolation is the first item on this list because it is the one with the most severe failure mode. A billing bug is embarrassing. A tenant data leak is company-ending.

1. Tenant isolation is enforced at the database level — every table that contains tenant-specific data has a tenant_id column, and every query that touches those tables filters by tenant_id. This is not something to verify by reading the code — write a test that proves a user from Tenant A cannot retrieve data belonging to Tenant B.

2. Row-level security (RLS) is configured — if you are using PostgreSQL on Supabase or another provider that supports RLS, policies are defined and tested. RLS as a defense-in-depth layer does not replace application-level filtering, but it catches the class of bug where a filter is accidentally omitted.

3. Environment separation is complete — production, staging, and development use separate databases, separate third-party API keys, and separate configuration. There is no code path that could accidentally write production data from a staging environment.

4. Environment variables are managed correctly — secrets are not in the codebase, not in the repository history, and not in .env files checked into version control. They are in a secrets manager, a platform secrets store, or at minimum a .env file that is explicitly in .gitignore with the .gitignore verified.

5. Database backups are configured and tested — automated daily backups exist, the retention period is defined, and you have actually run a restore from backup at least once. A backup that has never been restored is a backup you do not know works.

6. CI/CD pipeline is functional — every push to the main branch triggers automated tests and produces a deployable artifact. Deployments to production require a manual promotion step or are gated on passing tests. You have not deployed to production by running a script on your laptop.

7. Staging mirrors production — the staging environment uses the same infrastructure tier, the same secrets configuration approach, and the same deployment process as production. Differences between staging and production are the primary source of “it worked in staging” incidents.

8. Database migrations are version-controlled and automated — schema changes are never applied manually to the production database. Every migration is a file in the repository, runs as part of the deployment pipeline, and is reversible or at minimum documented for rollback.

9. Dependency versions are pinned — package.json or equivalent uses exact versions or a lockfile that is committed to the repository. npm install on a fresh checkout produces the same dependency tree today as it did six months ago.

10. Infrastructure-as-code or documented runbook — the production environment can be reproduced from scratch in under two hours using either code (Terraform, Pulumi) or a documented runbook. You are not dependent on one person who knows how it was set up.

---

Section 2: Authentication & Authorization

Authentication is the area where shortcuts cause the most irreversible damage. A compromised account is a support burden, a legal liability, and a trust problem simultaneously.

11. Managed auth service is configured correctly — if you are using Clerk, Auth0, or an equivalent, the dashboard settings match your intended behavior: allowed callback URLs are restricted, user metadata schema is defined, and test accounts do not have elevated permissions.

12. Password reset flow is end-to-end tested — a user who has forgotten their password can receive a reset email, click the link, set a new password, and log in. The reset token expires after a reasonable interval (15-60 minutes). Expired tokens produce a clear error, not a silent failure.

13. Email verification is required before full access — users who sign up with an unverified email address cannot access paid features or sensitive data. This blocks a category of abuse and ensures your user contact data is accurate.

14. Session expiry is configured — sessions expire after a defined period of inactivity. The expiry period is appropriate for your security requirements. A SaaS product handling financial data should have a shorter session window than a productivity tool.

15. Role-based access is implemented and tested — every route that serves data or performs an action verifies that the requesting user has the required role or permission. Authorization checks are at the business logic layer, not just the UI layer. A user who manually constructs an API request cannot access resources they are not authorized for.

16. Privilege escalation is impossible — a regular user cannot elevate their own role. A user cannot grant roles they do not themselves hold. An admin at one organization cannot modify users at a different organization.

17. Auth endpoints are rate-limited — the login endpoint, the password reset endpoint, and any endpoint that accepts credentials are rate-limited by IP and by account. Brute-force attacks against accounts are not possible at scale.

18. Auth events are logged — successful logins, failed login attempts, password changes, and role changes produce audit log entries with user ID, IP address, and timestamp. You can answer “who logged into this account and when” for any account.

---

Section 3: Billing & Payments

Billing is not a feature — it is infrastructure. A bug in your billing integration costs you revenue, erodes trust, and in the worst case exposes you to fraud. Test it like the infrastructure it is.

19. Stripe integration uses Customer objects — every user or organization that has ever had a paid relationship with your product has a Stripe Customer object, and the ID is stored in your database. You can look up any customer in both systems using either identifier.

20. Subscription objects are synced to your database — the source of truth for whether a user has an active subscription is your database, not a live Stripe API call on every request. Stripe webhooks keep your database in sync.

21. invoice.payment_failed webhook is handled — when a payment fails, your application takes appropriate action: notifies the user, restricts access if the dunning period has elapsed, and logs the event. This webhook fires in the real world — handle it.

22. customer.subscription.deleted webhook is handled — when a subscription is cancelled (by the customer, by you, or by Stripe due to payment failure), the user’s access is revoked in your database. You do not have users with cancelled subscriptions who retain access.

23. customer.subscription.updated webhook is handled — plan changes, trial end events, and reactivations all fire this webhook. Your application handles the plan change correctly: feature access is updated immediately, proration is handled by Stripe, and your database reflects the current plan.

24. Payment failure path is tested with Stripe test cards — use Stripe’s 4000000000000341 card to test a card that fails on charge. Confirm the user is notified, access is handled correctly, and the recovery flow (updating payment method) works.

25. Subscription cancellation is end-to-end tested — a user who cancels via the Stripe Customer Portal or your own UI has their cancellation reflected in your database. If you offer end-of-period cancellation, access persists until the period end. If you offer immediate cancellation, access ends immediately.

26. Invoice delivery is working — Stripe sends PDF invoices automatically when enabled. Verify that invoices are being sent to the correct email address, that the invoice includes your company name and address (required for VAT in many jurisdictions), and that the PDF renders correctly.

27. Free trial expiry is handled — if you offer a free trial, the trial end event fires a webhook, your application handles it, and users who have not added a payment method are notified before and after the trial ends. They do not simply lose access with no explanation.

---

Section 4: Security

Security for an MVP is not about building a SOC 2-ready system on day one. It is about closing the obvious attack surfaces that would embarrass you if discovered.

28. HTTPS is enforced on every endpoint — there is no HTTP endpoint that serves application data. HTTP requests are redirected to HTTPS at the infrastructure level. The TLS certificate is valid and auto-renewing.

29. Error responses do not leak internals — production error responses return generic messages, not stack traces, file paths, or database query details. Internal error information is logged server-side but never returned to the client.

30. SQL injection is not possible — all database queries use parameterized queries or an ORM that generates parameterized queries. There are no string-concatenated SQL queries anywhere in the codebase. Verify with a search, not a code review.

31. Dependency vulnerability scanning is configured — npm audit, Snyk, or Dependabot is integrated into the CI pipeline. The current dependency tree has no known critical vulnerabilities. You have a process for responding to newly disclosed vulnerabilities.

32. Rate limiting is applied to sensitive endpoints — authentication endpoints, password reset endpoints, and any endpoint that sends email are rate-limited. API endpoints that perform expensive operations are rate-limited to prevent abuse.

33. CSRF protection is in place — state-changing requests (POST, PUT, DELETE) from browser clients are protected against cross-site request forgery. If you are using a Next.js or similar framework with built-in protections, verify they are not disabled.

34. CORS is configured correctly — the CORS policy for your API allows only origins you control. The wildcard * origin is not set for endpoints that accept authenticated requests.

35. Sensitive data is not logged — your application logs do not contain passwords, payment card numbers, session tokens, or other sensitive user data. Review log output in staging before launch.

36. GDPR/privacy consent is implemented — if you process data of EU residents, a cookie consent mechanism is in place, privacy policy is linked from signup and the footer, and data deletion requests can be fulfilled. This is not optional if you are targeting European customers.

37. Security headers are configured — at minimum: Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, and Content-Security-Policy with a reasonable policy. Tools like securityheaders.com will scan your production URL and grade your configuration.

---

Section 5: Observability & Error Tracking

You will not be present when your product breaks. Observability is the infrastructure that tells you it broke before your users do.

38. Error tracking is live in production — Sentry or an equivalent is installed, configured with your production environment, and has captured at least one test event. You know how to navigate to a specific error, see its stack trace, and mark it resolved.

39. Alerting is configured on error tracking — new errors in production trigger a notification to a channel you actually monitor (email, Slack, PagerDuty). You do not check Sentry manually — it pushes to you.

40. Uptime monitoring is active — an external monitor (Better Uptime, UptimeRobot, or equivalent) is checking your production URL on a 1-5 minute interval. Downtime triggers an alert. You will not find out about an outage from a user tweet.

41. Application logs are structured and searchable — logs are written in a structured format (JSON) and are queryable. You can answer “what did user X do in the last hour” from your logs in under two minutes.

42. Performance baselines are established — you have run the core user workflow under load at least once and have a baseline for response times. You know what “normal” looks like so that you will recognize “abnormal” when it happens.

43. Background job failures are visible — if your application runs background jobs (email sending, webhook processing, scheduled tasks), failed jobs produce visible errors. They do not silently fail and drop data.

---

Section 6: Launch Readiness

The items in this section are frequently treated as administrative tasks and scheduled for “after launch.” Every one of them has a failure mode that is better discovered before your first customer than after.

44. Custom domain is configured and propagated — the product is accessible at your brand’s domain, not a provider subdomain. DNS has propagated fully. The TLS certificate on the custom domain is valid.

45. Transactional email is configured with a real domain — signup confirmation, password reset, and payment notification emails are sent from an address at your domain (not noreply@sendgrid.net). SPF, DKIM, and DMARC records are configured. Send a test email to a Gmail account and verify it is not in spam.

46. Privacy policy and terms of service are accurate — these documents exist, are linked from the signup flow and the footer, and actually describe what your product does with user data. A generic privacy policy template that references services you do not use is a legal liability.

47. Data backup restore has been tested — you have restored from a database backup at least once. The restore procedure is documented. You know approximately how long a restore takes and what data would be lost in a worst-case scenario.

---

Using This Checklist

Print it. Run through it with the person most familiar with each area of the codebase. Be honest about what is actually done versus what is assumed to be done. “I think we handle that” is not a pass — verify it.

The items that fail most often are not the ones in the architecture section. Architects remember to think about multi-tenancy. The items that fail are the boring operational ones: the backup that was configured but never tested, the webhook handler that processes the happy path but not the failure case, the rate limiter that was installed but not applied to the password reset endpoint.

The cost of finding these gaps during a pre-launch review is low. The cost of finding them after your first paying customer has encountered them is not.

---

If you are early in your MVP build and want to understand what goes into the architecture decisions that precede this checklist, our SaaS MVP development guide covers the full technical playbook. For the security items on this list and why each matters, SaaS security best practices goes deeper on the threat model. For a breakdown of what an MVP build actually costs, our custom SaaS development cost guide covers it by tier.

Zulbera builds SaaS MVPs from architecture through production launch. If you are approaching launch and want an independent technical review against this checklist, talk to us.