The MVP Feature Checklist: What to Build, What to Cut, and Why

What you actually need to know

• The MVP includes only what is needed to test the hypothesis. "Would users like this?" is the wrong question. "Does this test whether users will pay for the core value?" is the right question.
• Team features, analytics dashboards, third-party integrations, and customization settings are almost always post-MVP.
• Manual processes are legitimate MVP substitutes for features that can be built after the hypothesis is validated.
• The scope creep that delays MVP launch is almost always features that test user desirability, not features that test the hypothesis.
• In regulated industries, compliance features are infrastructure -- they belong in the MVP regardless of hypothesis testing.

The core argument

The MVP that is too large is the most common failure mode in startup engineering. Not the MVP that launches too soon -- the MVP that takes six months to build because the founder kept adding features, each individually reasonable, until the scope became a full product rather than a hypothesis test.

The cause is evaluating features on desirability ("users would love this") rather than on hypothesis necessity ("this is required to test whether users will pay for the core value"). These are different evaluations that produce different scopes. The desirability evaluation produces an MVP that is feature-complete but expensive and slow. The hypothesis-necessity evaluation produces an MVP that is minimal but fast and informative.

The insight is that a user who tries the MVP and finds the core value will tell you what else they need. A user who never tries the MVP because it was delayed by six months of feature development cannot tell you anything. The minimum viable product is not "the minimum features that make users happy" -- it is "the minimum features that test the hypothesis quickly enough to inform the decision."

The hypothesis formulation

Before evaluating any feature, the hypothesis must be explicit. An implicit hypothesis produces fuzzy feature decisions; an explicit hypothesis produces clear ones.

A usable hypothesis format: "We believe [type of user] will pay [price point] for [product capability] because [problem it solves]."

Examples:

• "We believe small business owners will pay $49/month for automated invoice reminders because they lose significant revenue to late payments and cannot afford a full-time AR person."
• "We believe independent financial advisors will pay $99/month for a client reporting tool because they spend 8+ hours per month manually compiling reports that their clients expect."
• "We believe restaurant operators will pay $199/month for shift scheduling software because they currently use spreadsheets that take 3+ hours to update and produce errors."

With the hypothesis stated, feature decisions become tractable. For the invoice reminder product: does a mobile app change whether small business owners will pay $49/month for automated invoice reminders? No -- a web app tests the same hypothesis. Is it needed? No.

Applying the checklist to a specific MVP

For the invoice reminder product with the above hypothesis:

Include (hypothesis-required):

• Customer/invoice management interface (minimum fields: customer name, email, invoice amount, due date)
• Automated reminder schedule (3 emails: 7 days before, on due date, 7 days after)
• Email delivery (Resend with a basic template)
• User authentication (Clerk)
• Billing (Stripe, monthly subscription)
• Basic dashboard showing pending invoices and reminder status

Exclude (post-MVP):

• QuickBooks/Xero integration (manual import via CSV works for the first 30 users)
• Custom reminder schedules (the default schedule tests whether the product works)
• Team member accounts (the hypothesis is about individual business owners)
• Mobile app (web app tests the hypothesis)
• Analytics dashboard (the founder can check the database directly for MVP metrics)
• Invoice PDF generation (link to an existing invoice in the email body)
• Payment processing (the product reminds, not processes payments -- stay in scope)

This produces an MVP that is buildable in 3-4 weeks by one developer. The 6-month version includes all of the excluded features and does not test the hypothesis any better than the 4-week version.

The manual process approach

For features that are post-MVP but that specific early users request, the manual process is a legitimate short-term substitute:

QuickBooks integration: For the first 20 customers, provide a CSV import template that the user fills in from their QuickBooks export. Process the import manually if needed. This takes 30 minutes per customer; at 20 customers, it takes 10 hours total -- significantly less than building a QuickBooks integration. After 20 customers, you know whether the integration is worth building.

Custom reminder schedules: When a customer asks for a different schedule, configure it manually in the database. This is not scalable past 50 customers, but at MVP scale it allows testing whether schedule customization is a retention factor before building the UI for it.

Analytics dashboard: Export data from the database periodically and present it to the customer in a shared spreadsheet. This is manual but allows testing whether customers want analytics before building a dashboard.

The principle: the manual process confirms that the feature is valuable before it is built. Building the feature first, then discovering that customers do not actually use it, is the waste that the manual process prevents.

The regulation exception

In regulated industries, compliance is not a hypothesis test -- it is a market entry requirement. The MVP in these categories is larger than in unregulated categories, and that is correct.

Healthcare (HIPAA): HIPAA-compliant data handling, audit logging, business associate agreements, and access controls are required for any product that handles protected health information. These are in the MVP regardless of whether they test the core hypothesis. Building without them is not an MVP -- it is a product that cannot legally be used by the intended customers.

B2B SaaS (SOC 2): Enterprise customers increasingly require SOC 2 Type II compliance. The compliance program is expensive but may be required to close the first enterprise contracts. For a product targeting enterprises, SOC 2 infrastructure is closer to MVP-required than post-MVP optional.

Fintech: Financial regulations (money transmission, KYC/AML, lending regulations) vary by jurisdiction and product type. Legal counsel is required to scope compliance requirements before development begins -- building a fintech MVP without this clarity risks building a product that cannot legally operate.

Common mistakes founders make with MVP scope

1. Adding features because competitors have them. The competitor's feature set is their answer to their hypothesis, not yours. Features that tests whether your hypothesis is true may be completely different from the competitor's features.
2. Not cutting features when the team pushes back on cuts. The developer who says "that would only take two days" is evaluating by effort, not by hypothesis necessity. Two days is not the criteria; hypothesis testing is.
3. Over-engineering the features that are included. An MVP that includes the right features but builds each one to production quality (with full test coverage, edge case handling, and documentation) is as slow as an MVP that includes too many features. Build the included features at MVP quality: functional, not polished.
4. Not tracking which excluded features users actually request. The cut features list is a backlog. Keep it and track how frequently each cut feature is requested by users. High request frequency after launch informs the post-MVP roadmap.
5. Treating the MVP as the product rather than as the hypothesis test. The MVP is not the thing; it is the test. After the test produces results, the product is built based on what the test showed. Teams that treat the MVP as the product optimize for the wrong outcome.

Where to start: a 3-step MVP scope decision

Step 1: Write the explicit hypothesis in one sentence. Who pays, how much, for what capability, because of what problem. If the hypothesis cannot be written in one sentence, it is not clear enough to build against.

Step 2: List every proposed feature and ask: "Does removing this feature change whether the hypothesis is true or false?" Features that survive this test are MVP-required. Features that do not survive are post-MVP unless they have a regulation requirement.

Step 3: For each post-MVP feature that specific beta users request before launch, design the manual process that provides the feature without building it. The manual process takes 30-60 minutes to design and runs at MVP scale without engineering investment.

The Scope That Teaches You Something

Yashveer Singh. Founder of Yashveer Labs. The first version of Expert Tutorials had nine features on the proposed feature list. Five were cut with the hypothesis-necessity test: a mobile app, a social learning feed, gamification badges, a content recommendation engine, and an instructor analytics dashboard. The three features that remained were: course content delivery, student progress tracking, and billing. The MVP launched in four weeks instead of twelve. Of the five cut features, two were eventually built (the instructor analytics dashboard and the recommendation engine -- both validated by user requests after launch). Three were never built because the hypothesis test revealed they were not the right features for the product direction. The twelve weeks not spent on the three never-built features paid for six months of product iteration based on what users actually valued.

Related reading

• The Five Hour Founder Audit: Are You Ready to Build?
• The Modular MVP: Building So You Can Pivot Without Burning Everything
• The Honest MVP Checklist: 25 Items Before You Launch
• The Lean MVP Stack for 2026: What I Use for Client Projects