What to Include (and What Not To) in a Minimum Viable Product
How to define what goes in your MVP and what doesn't. A framework to separate the essential from the nice-to-have, with real examples and the list of features that almost never belong in a first launch.
The word "minimum" in MVP is the hardest one to respect. Because there's always a seemingly valid reason to add one more feature: "users will ask for it", "the competition has it", "without this it doesn't look like a complete product".
The result is an MVP that takes 4 months instead of 6 weeks, costs twice the estimate, and still hasn't answered the question that justified building it: does anyone actually want this?
This guide gives you a framework for deciding what's in and what's out, with concrete examples and the list of features that — barring very specific exceptions — shouldn't be in any first launch.
Building your startup without a technical co-founder?
The definition error: what an MVP really is
An MVP is not the smallest version of your final product. It's the cheapest experiment you can run to answer the most important question about your business.
That question is usually one of these:
- Is anyone willing to pay to solve this problem?
- Can our product solve the problem better than the current alternatives?
- Is there enough demand to justify building the full product?
When the MVP is defined as "an experiment to answer X", the decision about what to include becomes objective: is this feature necessary to answer X? If not, it doesn't go in the MVP.
The 3-level framework
Classify every proposed feature into one of these three levels:
Level 1 — Critical to answer the core hypothesis Without this feature, the MVP can't answer the question that justifies building it. If your hypothesis is "users are willing to pay for X", you need X and the payment flow. Without the payment flow, you can't answer the hypothesis.
Level 2 — Needed for the product to work, but not a differentiator Sign-up, login, basic account management, transactional confirmation emails. These features have to exist for the product to be usable, but they're not the ones that will tell you whether the market wants the product.
Level 3 — Desirable but not essential for validation Everything else. Push notifications, integrations with external tools, advanced personalization, a full admin panel, multi-language, dark mode. Features that will improve the product but don't affect the MVP's ability to answer the core hypothesis.
The rule: Only Level 1 and Level 2 go in the MVP. Level 3 goes to v1.1.
What almost never belongs in an MVP
A full admin panel
At initial launch, the team can manage data directly from the database or with simple tools (Retool, Metabase, even an exported spreadsheet). A full admin panel — with user management, roles, data export, advanced filters — is a 3–4 week project that adds no value to the end user.
Exception: If the product has an operational component where the startup team has to manually manage real-time flows (content moderation, support that requires quick actions on the database), a minimal admin panel may be necessary from the start.
Push notifications and marketing emails
App push notifications and email marketing campaigns are retention tools. Retention is a week 4–8 problem for a product in production, not a launch-day problem.
In the MVP, a sign-up confirmation email and a transactional email for critical actions (booking confirmed, payment processed) are enough.
Integration with every possible provider
"We need login with Google, Facebook, Apple and email." In the MVP, email login is enough for 80% of products. Google login adds 1–2 days of development; Apple login adds 3–5 days (Apple's setup process is notoriously complex). Those days are better invested in the core flow.
Multi-language
Unless the MVP is explicitly built for a bilingual market, multi-language is v1.1. Internationalizing an app after the fact is more expensive than building it in from the start, but less expensive than delaying the launch for it.
A test / sandbox mode for users
Test environments are tools for enterprise customers. In the MVP with your first 50–100 users, you can handle test cases manually.
"When the company grows" features
"When we have 10,000 users, we'll need administrators to manage role-based permissions." That's true. It's also irrelevant for a product that has 0 users today. Scale features are built when they're needed, not before.
Complex internal metrics and dashboards
In the MVP, basic Google Analytics + Sentry for errors is enough. An internal analytics system with custom dashboards is a product-management tool, not a launch requirement.
What does belong in any MVP
The complete core flow, frictionless
The flow that demonstrates the product's core value has to be flawless. Not perfect in design, not complete in features, but free of friction that stops the user from reaching the moment they understand why the product is valuable.
If your product's core value is "do X in Y steps", that flow has to work perfectly. Everything else can be rough; that flow can't.
Sign-up and basic authentication
It doesn't need to be elaborate. Email + password (or magic link) is enough for most cases. What can't fail: the confirmation email, password reset, persistent session.
A mechanism to collect feedback
This is the most often forgotten. The MVP is an experiment, and you need instruments to measure the result. At a minimum: an in-product feedback form, basic behavioral analytics (Mixpanel or PostHog with the core events), and a way to contact active users.
Basic error handling
Error messages don't need to be perfect. What's needed is that errors aren't silent: when something goes wrong, the user knows it and has a way to resolve it or contact support.
Non-negotiable basic security
HTTPS, hashed passwords, credentials out of the code, authentication on every route that accesses private data. These aren't optional even if the MVP is "just to validate": they're protecting real data from real users.
The exercise that changes the conversation
When the team debates what to include in the MVP, this exercise helps cut the debate short:
Write on a card: "The MVP validates that [core hypothesis]. To validate it, the user needs to be able to [minimum action]."
Every feature that isn't necessary for that minimum action goes to v1.1.
The hypothesis forces you to be specific. And when you're specific, the decision about what to include becomes much easier.
At Collybrix we define the MVP scope before writing a single line of code, to make sure what gets built answers the right question. Tell us what you're working on →
More on the full MVP development process: MVP Development
Building your startup without a technical co-founder?