An MVP should include 3 to 5 features that together enable one complete user journey from signup to first value, and nothing else. That is the entire decision rule. Every feature that does not contribute to that single journey belongs in the version-two backlog, not the launch build. The founders who miss their MVP timelines are almost never under-building; they are over-building, treating the MVP as a first draft of the full product rather than as a validation instrument for a single hypothesis.
This guide covers which features every MVP needs regardless of product type, how to build a specific feature list for your product category, the three prioritization frameworks worth using, five tests to apply before any feature makes the cut, and the eight features that consistently appear in MVP scopes when they should not.
The feature inclusion test (use this before every scoping decision) Ask one question about each proposed feature: "Can a user complete the core journey and experience the product's primary value without this feature?" If the answer is yes, the feature does not belong in the MVP. Apply this test before using any prioritization framework. It is faster and more honest than any scoring system. |
The One Rule That Determines Every MVP Feature Decision
Every feature decision in an MVP comes back to one question: does this feature enable the core user journey, or does it decorate it? The distinction matters because decoration feels like value but does not generate the behavioral evidence that makes an MVP useful. An analytics dashboard looks impressive in a demo. It does not tell you whether the product solves a real problem for a real user.
The core user journey is the smallest sequence of steps a user must complete to experience the primary value of the product. For a project management tool, that journey is: create an account, create a project, add a task, mark it done. Everything else (integrations, reports, notifications, team invites) exists to enhance a journey that first needs to prove it is worth taking.
This is also why the definition of "minimum" in minimum viable product matters so much. Minimum does not mean lowest quality. It means the smallest possible scope that allows a user to complete that journey with production-quality reliability. Our guide to what an MVP is covers the six types of MVP and what each one is designed to prove, which shapes the feature list before you even start prioritizing.
Scope before you stack The features in your MVP determine which tech stack you need, which affects your timeline and cost. Locking the feature list before choosing technology saves 2 to 4 weeks and prevents building with a stack that cannot support the features you add in version two. |
How Many Features Should an MVP Have?
A well-scoped MVP has 3 to 5 features. If your list has more than 5, you are building a version one product, not an MVP. The number is not arbitrary: 3 to 5 features is the range that fits inside a 8 to 14-week development timeline with a dedicated team, generates enough user behavior to be measurable, and stays narrow enough that failure signals point clearly to the hypothesis being tested rather than to any of a dozen unrelated features.
The founders who fight this constraint usually make one of two arguments. The first is that their product is uniquely complex and cannot be validated with fewer features. The second is that users will not find value without a more complete experience. Both arguments are almost always wrong. Dropbox validated cloud file syncing with a demo video. Airbnb validated the willingness to sleep in strangers' homes by photographing apartments and listing them manually. The hypothesis being tested rarely requires as many features as the founder assumes.
The practical test: write down every feature you plan to include, then ask of each one, "If we launch without this feature and our first 100 users do not notice it is missing, was it a Must Have?" Most lists shrink by 40 to 60 percent when that question is applied honestly.
Must-Have Features in Every MVP (Regardless of Product Type)
Four categories of features belong in virtually every software MVP, regardless of whether you are building a SaaS platform, a marketplace, or a mobile consumer app. These are not glamorous features. They are the unsexy infrastructure that makes the rest of the product trustworthy enough to learn from.
User Authentication
Every MVP needs a working login system. This means account creation, email and password authentication, password reset, and at minimum one social login option (Google OAuth covers the majority of user preference). Authentication is not optional or deferrable: without it, you cannot tie behavior to individual users, cannot measure retention, and cannot charge for access. Build it properly from day one using a proven library (Supabase Auth, NextAuth, Clerk) rather than rolling custom session management.
The Core Value Loop
This is the one feature your MVP exists to validate. It is the thing users do when they experience the product's primary value. For a SaaS tool that helps freelancers track invoices, the core value loop is: create an invoice, send it, receive payment confirmation. Everything before and after that sequence is scaffolding. Build this feature to production quality, not prototype quality. It is the only thing in the MVP that cannot be rough around the edges.
Onboarding and First-Use Experience
Users who do not reach the core value loop within their first session rarely return. Activation, the moment a user first experiences what the product actually does, is the most fragile point in the entire user journey. An MVP needs a minimal onboarding flow that gets users to the core value loop as fast as possible. This does not mean a six-step tutorial wizard. It means removing every unnecessary step between account creation and first value. For most products, that is an empty state with a single clear call to action and one tooltip or prompt.
Analytics and Event Tracking
An MVP without analytics is a product launch without a measurement instrument. You cannot know whether users are reaching the core value loop, where they drop off, or which features they actually use if you have not set up event tracking before the first user logs in. Install PostHog or Mixpanel in Sprint 1, define the events that map to your MVP success metrics before launch, and instrument every step in the core value loop. Founders who defer analytics to "after we have users" are making decisions based on assumption at exactly the moment when behavioral data is most available.
Basic Error Handling and Empty States
The user experience of an MVP that crashes gracefully is fundamentally different from one that shows a raw stack trace or a blank white screen. Empty states (what users see when they have not created any data yet), error messages (what they see when something fails), and loading states (what they see while the app processes their request) are not polish features. They are the difference between a user who churns immediately and one who understands what went wrong and tries again. They take one sprint to build and pay for themselves in retention.
MVP Feature List by Product Type
The universal must-haves apply to every MVP, but the specific feature list inside the core value loop varies significantly by product category. The cards below define what belongs in the MVP, what belongs in version one after traction, and what should not be discussed until you have paying users.
Product Type 1 SaaS Platform Must include in MVP: Auth (email + Google OAuth), single-tenant data model, the one core workflow that delivers primary value, Stripe billing (checkout and subscription), basic user dashboard showing core data, transactional email for signup and key triggers. Nice to have in V1 (not MVP): Role-based access control, team invites, usage-based billing tiers, in-app notifications, onboarding email sequence beyond day one. Cut entirely until traction: Admin super-panel, referral system, multi-language support, public API, SSO / SAML, multi-tenancy, advanced reporting, CSV exports. |
Product Type 2 Two-Sided Marketplace Must include in MVP: Auth for both sides (buyer and seller), seller onboarding (profile + listing creation), buyer browse and search (simple, not Algolia-level), single transaction path (payment + confirmation), basic messaging between parties, email notifications for transaction events. Nice to have in V1 (not MVP): Review and rating system, saved searches, featured listings, seller analytics dashboard, buyer wish lists, discount codes. Cut entirely until traction: Dispute resolution system, advanced search filters, recommendation engine, loyalty program, third-party logistics integration, seller subscription tiers. |
Product Type 3 Consumer Mobile App Must include in MVP: Auth (email + Google/Apple OAuth), push notification opt-in, core feature loop (the one thing the app does), basic profile, app store listing (screenshots, description, privacy policy). Nice to have in V1 (not MVP): Social sharing, friend discovery, in-app purchases beyond a single product, personalization based on behavior, deep linking. Cut entirely until traction: Native camera or AR features (unless core), offline mode, social graph, gamification layer, referral program, multiple content verticals. |
Product Type 4 Internal Tool or Admin Dashboard Must include in MVP: Auth (SSO is acceptable if the org already uses it), the one view or workflow that replaces the existing manual process, read and write access to the relevant data source, basic filtering or search of records. Nice to have in V1 (not MVP): Role-based permissions, export to CSV, activity audit log, Slack notifications on key events. Cut entirely until traction: Custom theming, public-facing views, multi-org support, complex workflow automation, SLA tracking, ticketing system integration. |
Product Type 5 AI-Native Product Must include in MVP: Auth, the LLM-powered core interaction (prompt, response, display), basic output quality controls (regenerate, thumbs up or down feedback), usage limits or token budgeting to prevent runaway costs, simple history of past interactions. Nice to have in V1 (not MVP): Fine-tuning pipeline, RAG document upload, streaming responses, custom model selection, output export. Cut entirely until traction: Multi-model comparison, agent orchestration, plugin system, voice input, image generation, enterprise knowledge base ingestion. |
The tech stack you choose has a direct effect on how fast you can build the features in each card above. Certain stacks come with auth, billing, and database pre-wired, saving 2 to 4 weeks compared to building from scratch. Before finalizing your feature list, read through the MVP tech stack comparison to understand which combinations will let you ship the core value loop fastest.
3 Feature Prioritization Frameworks Worth Using (And When to Use Each)
Prioritization frameworks are useful when the subjective debate between founders, developers, and stakeholders about what to include is producing more heat than light. They are not useful as a replacement for talking to users. Use them to structure a conversation, not to avoid one. The three frameworks below cover the majority of MVP scoping situations.
Framework | How It Works | Best Used For | Limitation | When to Use |
|---|---|---|---|---|
MoSCoW | Must / Should / Could / Won't. Sorts features into release buckets. | Quick team alignment on what is in and out of scope. Works in one session with stakeholders. | Subjective. No quantitative scores. Stakeholder bias can inflate "Must" bucket. | First pass at any new project. Fastest framework to run. |
RICE | Score = (Reach x Impact x Confidence) / Effort. Each feature gets a number. | Comparing a large backlog objectively. Removes opinion from roadmap debates. | Time-consuming to score accurately. Requires data for Reach and Confidence estimates. | When you have 10 or more features competing for limited sprint capacity. |
Kano Model | Classifies features as Basic (expected), Performance (more = better), or Delighters (unexpected but valued). | Understanding which features will delight vs. which merely prevent dissatisfaction. | Requires user surveys to classify accurately. Less useful without existing user base. | When shaping UX and deciding where to invest in polish vs. functionality. |
80/20 Rule | 20 percent of features deliver 80 percent of user value. Identify that 20 percent. | Cutting scope ruthlessly when timeline is the primary constraint. | Requires honest assessment of what actually drives value, which founders often get wrong. | Final scope review before development starts. Pair with MoSCoW results. |
For most early-stage MVPs, the fastest path is to run MoSCoW with your co-founder and a potential customer in the same room, then apply the 80/20 filter to whatever lands in the "Must Have" bucket. RICE is valuable later, when you have a backlog of 20 or more ideas competing for the same sprint capacity. Kano is valuable when you are trying to understand which features will create delight rather than simply preventing dissatisfaction, which is a version-two question, not a launch question.
One note on the "Won't Have" category in MoSCoW: every feature in that bucket should be written down somewhere visible. Founders who document their "Won't Have" decisions are dramatically less likely to re-litigate them mid-sprint when someone says "can we just add..."
5 Tests to Run on Every Feature Before It Makes the Cut
Framework scores are useful but they can be gamed by motivated founders who want to include a feature they are attached to. These five tests are harder to manipulate because they require specific, honest answers rather than subjective ratings.
Test 1: The Journey Test
Can a new user complete the core user journey and experience primary value without this feature? If yes, it is not a Must Have. This is the fastest filter. Apply it first to every item on the list before running any framework.
Test 2: The Delay Test
Would you delay the launch date by one week to include this feature? If the honest answer is no, the feature does not belong in the MVP. This question forces founders to make a real cost-of-delay calculation rather than treating every feature as equally important. Most feature lists shrink significantly when applied.
Test 3: The Hypothesis Test
Which specific assumption does including this feature help you validate? If you cannot name the assumption, the feature is not generating learning. It is generating product. MVP features exist to produce evidence. If a feature does not help you confirm or deny a specific hypothesis about your users or your market, it belongs after launch.
Test 4: The Fake It Test
Can this feature be simulated manually for the first 100 users without being built? Concierge MVPs and Wizard of Oz MVPs exist precisely because many features that feel like technical requirements can be handled by a person on the backend for the first month of users. If you can fake it, fake it. Build only when the manual approach breaks down under volume.
Test 5: The "Already Solved" Test
Is this feature already solved by a third-party service that can be integrated in one to two days? Authentication, payments, email, file storage, and maps are all solved problems. Any feature in those categories should be bought, not built. The only things worth building from scratch are the features that are unique to your product and that no existing service provides adequately.
Features that pass all five tests belong in the MVP. Features that fail any one of them belong in the backlog. Print this list and go through it with your co-founder or development partner before the discovery sprint ends. Any feature that generates disagreement on one of the five tests is a feature that needs more user research before it enters the build. |
8 Features That Almost Always Belong in Version Two, Not Your MVP
These eight features appear in MVP scopes constantly. They are not wrong features for a product. They are wrong features for a launch. Each one adds weeks to your timeline, increases development cost, and generates no additional validation evidence in the first 90 days. The table below documents why founders want each one, why it does not belong in the MVP, and what to do instead.
Feature | Why Founders Want It | Why It Does Not Belong in MVP | What to Do Instead |
|---|---|---|---|
Advanced notifications | Feels like polish; founders assume users expect it | Email on signup and key triggers is enough. Push and in-app bells distract from fixing the core loop. | Wire email with Resend or SendGrid for transactional triggers. Add push post-launch when you know which events matter. |
Referral or affiliate system | Viral growth sounds like an MVP feature | You cannot optimize referral until you know what users find worth sharing. Referral built before retention data is referral built for the wrong thing. | Launch without it. Add after your Day 30 retention is stable and you know the "aha moment" worth sharing. |
Admin super-panel | Founders want visibility into all their users | PostHog, Mixpanel, and your database dashboard give you everything you need in the first 90 days without a custom admin. | Use your analytics tool and a read-only database client. Build admin only when support volume makes it necessary. |
Multi-language / i18n | Global ambitions feel urgent | You have no localization data yet. Build for one language, validate traction, then expand. | Hard-code English. Use i18n-friendly string architecture from day one so adding languages later is fast, but do not build the switcher. |
Mobile app (native) | Users expect mobile | A responsive web app covers 90 percent of mobile use cases at launch. App store review adds 2 to 3 weeks and native development doubles the scope. | Ship a progressive web app or a mobile-responsive web product first. Build native only after you have proven retention on web. |
Social login for all providers | Google plus Apple plus GitHub plus Facebook looks professional | Google OAuth covers over 80 percent of user preference for social login. Each additional provider adds an integration, a review process, and ongoing maintenance. | Ship Google OAuth only. Add Apple sign-in if the App Store requires it. Defer everything else. |
Reporting and exports | "Data export" appears in every competitor feature list | Your first 100 users do not need a CSV export. They need the product to work. Reports are a retention and upsell feature, not a launch feature. | Give users access to their data via the UI. Add exports when users specifically request them in support tickets. |
Team / multi-seat accounts | B2B founders want enterprise-ready collaboration | Single-user accounts are faster to build and validate. Multi-seat logic (invites, roles, billing per seat) adds 3 to 5 weeks to development scope. | Launch with single accounts. Collect evidence of team use demand from actual users before building collaboration. |
The pattern across all eight is the same: each feature addresses a problem that does not yet exist at MVP scale. Referral systems optimize growth that has not yet proven it should be grown. Admin panels manage users who have not yet arrived. Multi-language support translates content for markets that have not yet been validated. Every hour spent building these features is an hour not spent learning whether the core product works. Over-scoped MVPs cost more and teach less. Our full MVP development cost breakdown shows exactly how each additional feature category translates to development weeks and budget, which makes these scope decisions concrete rather than abstract.
The Feature Conversations That Will Derail Your Scope
Scope decisions are made in conversations, and certain conversations reliably produce bad scope decisions. Recognizing these patterns before they happen is the best defense against them.
"Our competitors have this feature, so we need it too"
Competitor feature parity is a post-traction goal, not a launch requirement. Your competitor built that feature after they had users telling them they needed it. You are building before you have users. The feature that a competitor added in year two of their product tells you nothing about what you need in week one of yours. The question is not "what do competitors have?" but "what do our first 10 users need to complete the core journey?"
"We will build it faster than you think"
Development time estimates made by optimistic founders or eager developers at the beginning of a project are systematically low. The realistic multiplier for most integrations and features is 1.5 to 2 times the initial estimate when you include error handling, edge cases, QA, and iteration from feedback. Features that sound like two days of work reliably take one to two weeks when built to production quality. Apply that multiplier before including anything in scope.
"We need it for the demo to investors"
Investors do not fund polished demos. They fund validated hypotheses, clear market signals, and founders who understand their users. A product with 50 active paying users and three features is a more compelling pitch than a product with 15 features and 10 users who signed up because of the feature count. Build what generates evidence, not what generates applause in a pitch meeting.
"Users will churn without it"
This argument is almost always made before talking to users. The assumption that users will leave without a specific feature is a hypothesis, not a fact. The correct response is to launch without the feature, measure whether churn actually increases, and then make a data-backed decision about whether to build it. Features added to prevent hypothetical churn before launch often have no measurable effect on retention and consume weeks that could have been spent on the core loop.
How long does it take to build these features? Every feature added to an MVP scope adds time to the development timeline. Our week-by-week MVP development timeline guide maps each feature category to realistic sprint estimates, so you can see exactly what a scope decision costs in time before you make it. |
How Adeocode Handles Feature Scoping for Non-Technical Founders
One of the most common conversations at Adeocode's intake calls goes like this: a founder arrives with a list of 18 to 25 features they want in the MVP. By the end of the discovery sprint, the build list is 4 to 6 features. The founder ships on time. The founders who push back on the cuts and insist on 15 features are the ones who are still building six months later.
Adeocode is a full-stack product studio in Chicago that runs 8-week MVP sprints for non-technical founders. The discovery sprint, which runs for the first two weeks of every engagement, produces one specific output: a locked feature list. Locked means signed off by the founder, documented in writing, and protected by a change-order process for the rest of the build. Features that do not make the discovery output do not appear in development. No exceptions.
The discovery sprint also defines the success criteria for each feature before any code is written. "Auth is done when a user can sign up, log in, reset their password, and connect Google OAuth in under three minutes." That level of specificity eliminates the ambiguity that produces scope creep and timeline overruns. If you want a development partner who will tell you what to cut rather than agreeing to build everything, learn more about how to choose an MVP development agency before starting the partner search.
Book a free scope call at adeocode.com. We will map your product to a feature list, tell you which features we would cut, and give you a fixed-price estimate for the discovery sprint before any commitment is made.
Scope Is the Product Decision
Every feature decision in an MVP is a resource allocation decision. Time spent building a referral system is time not spent polishing the core value loop. Features added to impress investors are features that did not get built to impress users. The founders who ship on time are the ones who made hard cuts early and protected those cuts throughout development.
The feature list in this guide is not about building less. It is about building the right thing to a standard of quality that actually generates the behavioral signal you launched to get. Three features that work flawlessly and drive 30 percent Day 30 retention are worth more than 15 features with a 4 percent retention rate. Scope for learning, not for completeness.
What features should an MVP include?
How many features should an MVP have?
What should NOT be in an MVP?
How do you decide which features to include in an MVP?
What is the core feature of an MVP?
Should MVP include billing?
The right MVP development agency compresses a 12-month idea-to-launch journey into 8 to 14 weeks and costs $30,000 to $150,000 depending on complexity and region. The wrong one takes the same money and the same time, then delivers something you cannot launch, do not own outright, or cannot maintain without them. The difference between those two outcomes is almost never technical skill. It is process, incentives, and the questions you ask before signing. This guide covers how to evaluate every type of development partner, the 12 questions that separate disciplined agencies from opportunistic ones, and the eight red flags that should end a conversation before it goes further.
Before evaluating agencies, make sure you have a clear answer to what your MVP needs to prove. The complete guide to what an MVP is covers the six types of MVP and what each one is designed to validate, because a landing-page MVP and a full-stack SaaS MVP require completely different types of partners.
Who this guide is for Non-technical founders evaluating development partners for the first time. Technical founders who want a structured framework to vet agencies against their own judgment. Anyone who has been burned by a previous agency relationship and wants to know what questions they should have asked. |
An MVP is successful when it generates reliable evidence that real users experience measurable value from the core feature set -- not when it gets downloads, press mentions, or five-star ratings. The metrics that actually tell you whether your MVP worked are retention at day 7 and day 30, activation rate from your first cohort, and the Sean Ellis test score: the percentage of users who say they would be "very disappointed" if the product disappeared. This guide covers every MVP success metric worth tracking, with industry benchmarks, warning thresholds, and the specific actions to take when a metric is telling you something is wrong.
The 5 metric categories every MVP should track Acquisition: how users find you Activation: how many reach the "aha moment" Retention: how many return Revenue: whether users pay and stay Referral: whether users recommend you (NPS, Sean Ellis score) |
Most MVPs take 8 to 16 weeks from validated concept to public launch, though simple single-workflow tools can ship in 4 to 8 weeks and complex regulated products often require 5 to 10 months. The gap between the best-case timeline you read in agency brochures and the real-world timeline you live through comes down to a small set of predictable, avoidable mistakes. The type of MVP you choose to build -- landing page, concierge, single-feature software, or full-stack platform -- is also one of the biggest timeline variables: our complete guide to MVP types and definitions walks through each option with realistic build estimates. This guide then breaks down the timeline phase by phase, product type by product type, and gives you the sprint-by-sprint plan used by teams that actually hit their launch dates.
Quick Reference: MVP Timeline by Complexity Simple MVP (1-2 features): 4-8 weeks Standard MVP (3-5 features): 8-14 weeks Complex MVP (6-10 features): 12-20 weeks Enterprise MVP: 5-10 months |
Choosing the wrong tech stack at the MVP stage is one of the most expensive mistakes a startup can make. Not because the wrong choice crashes the product on day one, but because it quietly accumulates technical debt that compounds into a full rebuild six months after launch, exactly when you are trying to raise a seed round and scale the team.
If you're evaluating your build options, working with a custom software development partner can help you avoid expensive technical mistakes early on.
This guide cuts through the noise. It gives you the default recommended stack for each type of MVP product, a technology-by-technology comparison across every layer (frontend, backend, database, auth, payments, hosting, and observability), real cost numbers at each user scale, the five stack mistakes that force the most expensive rewrites, and a decision framework for choosing between build options when your product type changes the calculus.
No generic advice. No technology recommendations that sound impressive but have three developers available to hire. Just the stack decisions that help non-technical founders move from idea to live product in the shortest time with the lowest future regret.