An MVP — minimum viable product — should be the smallest version of your product that allows a real user to solve their problem and give you signal about whether you have built the right thing. That is the definition. In practice, most SaaS MVPs are significantly larger than this.
Founders over-scope MVPs for a predictable set of reasons: fear that the product will not be impressive enough to convert users; genuine uncertainty about which features are load-bearing and which are optional; and the difficulty of saying no to features that feel important in the abstract.
This checklist is designed to help you cut to what actually needs to be in the MVP — and to be explicit about what does not.
Before you write a line of code
Define the core user journey in one sentence. "A [user type] can [do the one thing your product is for]." If you cannot write this sentence, you are not ready to scope the MVP.
Identify the one moment where the user gets value. Not the journey to that moment — the moment itself. Everything in the MVP should be in service of reaching that moment as quickly and reliably as possible.
List every feature you think the product needs. Then ask this question about each one: "If this feature is absent, does the core user journey fail?" If the answer is no, it does not go in the MVP. If you cannot answer the question, assume the answer is no.
Architecture decisions before you build
Choose your multi-tenancy strategy. This is not optional. Shared schema with row-level security is the right default for most early SaaS products. Do not defer this decision.
Choose your authentication approach. Use a managed auth provider — Clerk, Auth0, or Cognito. Do not build your own authentication layer for an MVP. This is a fixed cost that managed providers have already paid.
Choose your billing model and implement it from week one. Stripe with subscription billing. Do not launch without it, even if your first users are free. The billing infrastructure takes time to instrument correctly and the edge cases (failed payments, upgrades, cancellations) need to be handled from the start.
Choose your deployment model. Serverless functions on AWS Lambda or a managed container service. A managed database — RDS or Supabase. Do not manage your own servers at the MVP stage.
Document these decisions. A one-page architecture decision record created at the start is worth more than a backlog of undocumented choices that the next developer has to reverse-engineer.
What must be in the MVP
The core user journey. Whatever your product does — the thing that it is for — must work end to end. Not partially. Not with workarounds. End to end.
Authentication. Users must be able to create an account, log in, and log out. With a managed auth provider, this takes hours, not weeks.
Basic data isolation. If your product serves multiple customers, tenant isolation must be implemented from the start. See the multi-tenancy architecture decision above.
Billing infrastructure. At minimum, the infrastructure to charge a user must exist. An "upgrade" flow that connects to Stripe can be behind a button that says "upgrade to paid" even if you are not charging yet — but the infrastructure needs to be wired.
Error states. What happens when something goes wrong? An empty state, a failed API call, an input validation error? These are not polish. They are part of the core user journey.
A way to contact you. A link to an email address, a Crisp chat, a Cal.com booking link. Early users who hit a problem or have a question need a way to reach you. Every one of those interactions is data.
What does not go in the MVP
Administrative dashboards and reporting. No usage analytics, no management console, no audit logs. These come after you have users.
Email notifications. Every notification you build requires design, copy, testing, and maintenance. Defer all email notification logic until you have evidence that users want it. Your early users can tolerate checking the product manually.
Integrations. Third-party integrations are one of the most common sources of MVP overscope. Slack integration, Zapier, API access, webhooks — none of these belong in an MVP unless the core user journey cannot be completed without them.
Mobile applications. If your web product works on mobile browsers, a native mobile app is not an MVP requirement. Build it when you have evidence of user demand.
A/B testing infrastructure, feature flags, and advanced analytics. These are scaling tools. They require infrastructure investment and maintenance. Defer until you have a product worth optimising.
Multi-language and localisation support. If you are building for a specific market, build in that language. Do not build multilingual infrastructure speculatively.
Team and collaboration features. "What if users want to add team members?" is one of the most reliable ways to double scope. Add it when a user asks for it with enough specificity that you understand exactly what they need.
The scope review test
Before finalising MVP scope, run this test: estimate the time to build what you have scoped. Then cut it in half. Ask yourself whether the resulting product could still earn a real user's feedback. If the answer is yes — and it almost always is — you have over-scoped.
The instinct to build more than the minimum is not irrational. It comes from a genuine desire to give users something they will find valuable. But it misunderstands what users in the early stage are evaluating. Early users are evaluating the problem. They are not evaluating the completeness of the solution.
An MVP is not a beta of your final product. It is an experiment to test the most important assumption you have: that the problem you have identified is real, and that the solution you have designed addresses it. The experiment should be the smallest possible version that tests that assumption.
After the MVP ships
The most important thing to do after shipping is to talk to users. Not observe them — talk to them. Call them. Ask what they tried to do, what stopped them, what they would pay for, and what they would not miss if it disappeared.
The second most important thing is to resist adding features until you understand what you have heard. Every conversation will contain some feature request. Most of those requests are symptoms, not diagnoses. Find the underlying need before building the proposed solution.
The MVP is not done when it ships. It is done when you have enough signal to decide confidently what to build next.