Who this is for
Founders and small teams who have a specific idea, need to validate it with real users, and don't yet need — or can't yet justify the cost of — a fully-featured platform. See What Should Be Included in an MVP for how we decide what's actually in scope.
What "MVP" actually means here
The smallest usable product that lets a real user complete the core workflow end to end — not a prototype that only looks finished, and not a feature-complete platform. Cutting scope deliberately is the point, not a compromise.
What's typically included
- Core workflow, built end to end and genuinely usable
- Basic authentication and a single primary user role (multi-role usually comes later)
- A database for the data your core workflow actually needs
- Minimal but real UI — not a wireframe, not over-polished either
What's deliberately excluded, and why
Billing/subscription infrastructure, admin dashboards, multiple user roles and edge-case handling are usually left out of a true MVP — not because they're unimportant, but because validating the core workflow first tells you whether those investments are even worth making.
Beyond MVP: growing into a full SaaS product
If the MVP validates, growth adds what real usage showed you actually need — not a pre-planned feature list assembled before you had real users. The typical path, in the order it usually matters:
Multi-tenancy and account management
Separating each customer's data cleanly (multi-tenant architecture) becomes necessary once you have multiple paying accounts — this is architected differently than a single-user MVP and is worth planning for even if not built on day one.
Subscriptions, billing and usage limits
Recurring billing, plan tiers and usage limits (API calls, seats, storage) — see How to Plan Payments and Subscriptions in a SaaS Product for how this gets designed without becoming its own project risk.
User roles, admin tools and onboarding
Multi-role support (see How to Plan Roles and Permissions in a Web Application), an admin view for your own team, and a proper onboarding flow for new accounts all typically arrive in this phase, not the MVP.
AI features, integrations, analytics and support workflows
Product-embedded AI features (see How to Add AI to a SaaS Product), third-party integrations, usage analytics, and a support workflow for customer issues — added based on what real customers actually need, not speculatively.
Scaling and maintenance
As usage grows, infrastructure and maintenance needs change — this is planned for as part of ongoing product development, not assumed to be a one-time build with no further involvement. See Web Application Development for the general maintenance discipline this follows.
Questions
How is this different from a prototype or a design mockup?+
An MVP is a real, working product a user can actually use end to end — not a clickable mockup that only simulates functionality.
Do you only build MVPs, or also grow the product afterward?+
Both — this page covers the full path, from a narrow first validation build through multi-tenancy, billing, roles and scaling as the product grows.
When should multi-tenancy be added?+
Once you have (or are about to have) multiple paying accounts — retrofitting it later is more expensive than planning for it once it's genuinely needed.
Will you push me to add more features than I need?+
No — the point of an MVP is deliberately narrow scope; we'll say directly if a requested feature should wait until after validation.
What if the idea needs to pivot after launch?+
That's a normal, expected outcome of validation — a narrowly-scoped MVP is specifically easier to adapt than an over-built platform would be.