What to Include in an MVP (and What to Cut)

An MVP should include only what one specific user needs to reach one specific result, plus a way for you to learn whether it worked: the path to the value moment, a way to pay or commit, a way to measure, and a way to talk to users. Everything else can wait. The test for any feature is whether your first users would fail to get the result without it.

That was always the advice. What changed is the temptation. When a feature took weeks, scope was cut by necessity. Now AI tools build a feature in an afternoon, so MVPs quietly grow into full products before anyone has used them. The result is a product that's harder to learn from, not one that's more likely to work.

What an MVP actually is

Eric Ries, who popularized the term in The Lean Startup, defines a minimum viable product as the version of a new product that lets a team collect the maximum amount of validated learning about customers with the least effort.

The key word is learning. An MVP isn't a cheaper version of your final product. It's the smallest thing that can answer your riskiest question with real users. Usually that question is one of:

• Do these people have this problem badly enough to change what they do?
• Does our solution actually deliver the result?
• Will they pay for it, or commit something?

If a feature doesn't help answer the question, it isn't part of the MVP, however cheap it is to build. Cheap to build isn't cheap to have: every extra feature adds screens to learn, bugs to fix and noise in your data.

The five things every MVP needs

Include	Why	Minimum version
The core flow	The path from arriving to the value moment: the first booking, report or match	The fewest steps that deliver the result once
Access	A way in, and a way to come back	Email sign-in or magic link. One method.
A way to pay or commit	Interest is cheap; commitment is evidence	A payment link, a pre-order, or a founding price
Measurement	You need to know who reaches the value moment	Analytics on signups and on the value moment
A way to talk to users	Numbers tell you where people drop; conversations tell you why	Your email in the app and a booking link for calls

Plus the basics that protect users, which I'll come back to below. Those aren't optional at any stage.

The four-question test for every feature

List every feature you've built or planned. For each, ask:

1. Is it on the path to the value moment? If a user can get the result without it, it's a candidate to cut.
2. Does it help answer your riskiest question? If you'd learn the same thing without it, cut it.
3. Would your first 20 users leave without it? Not "would they like it". Would they leave.
4. Can you do it by hand instead? Reports you email manually, onboarding you do on a call, matching you do in a spreadsheet. Manual work is slow, but it's flexible and it teaches you what to automate.

Then sort the list:

• Keep: yes to question 1 or 3, and no to question 4.
• Do by hand: needed, but you can deliver it manually for now.
• Cut or hide: everything else.

A worked example

Say you're building a tool that reminds freelance designers to chase unpaid invoices. Your riskiest question is whether designers will pay to get paid faster. Here's how a typical AI-built feature list sorts out:

Feature	Decision	Reason
Add an invoice and its due date	Keep	The core flow starts here
Automatic reminder emails to clients	Keep	This is the value
Payment page for your own subscription	Keep	Tests whether they'll pay
Dashboard of paid vs unpaid invoices	Cut for now	Nice to see, not why they came
Import from accounting tools	Do by hand	Offer to set up the first users yourself
Custom email templates	Cut for now	One good default template is enough to test
Team accounts and roles	Cut	Your first users are solo freelancers
Mobile app	Cut	A mobile-friendly web page covers it
AI that predicts which clients pay late	Cut	Interesting, but it doesn't answer the question

Nine features become three, plus one manual task. That version ships faster, but more importantly, when it works or doesn't, you know why.

Features almost every first MVP can cut

• Admin dashboards (use your database's own interface for now)
• Multiple sign-in options
• User settings and preferences beyond the essentials
• Team accounts, roles and permissions
• Notification settings and multiple channels
• Integrations with other tools
• Both a web app and native mobile apps
• Multiple pricing tiers (start with one plan; here's how to price for your first customers)
• Multi-language support
• AI features added because they're easy, not because they deliver the result

Cutting can mean hiding instead of deleting. If a feature already exists, remove it from the interface and see if anyone asks.

Cutting isn't only an MVP habit. When I joined Balkanza, a social dating app, it was vibe-coded with no revenue. Focusing on value, cutting what didn't matter and doubling down on what did grew it to 25K+ users and $3K in monthly revenue.

What you should never cut

Minimum doesn't mean careless. Keep these from day one:

• Security basics: secret keys out of the browser, database access rules on, authorization checked on the server. The production-readiness checklist covers what AI tools tend to skip.
• Correct payments: prices set on the server, payment confirmations verified.
• Privacy: a privacy policy that matches what you collect, and only collecting what you need.
• Backups of anything users create.
• A way to reach you.

A small product that loses someone's data teaches you nothing except how to apologize.

Signs your MVP is too big

• You can't describe what it does in one sentence without "and".
• New users ask "what do I do first?"
• You've been building for weeks and nobody outside your circle has used it.
• Your analytics show users spread across many features, with no clear core.
• You're adding features to fix a lack of users.

If several of these are true, go back to the four questions. If your MVP is built and you're unsure what to do with it, I wrote a 30-day plan for the weeks after the MVP works. And if you haven't confirmed people want it at all, you may not need an MVP yet: validate the idea first, often with nothing more than a landing page and ten conversations.

Common questions

How many features should an MVP have?

There's no right number. Count user goals, not features: an MVP should let one type of user achieve one goal. If that takes three features, it has three. If you need ten, your MVP probably serves more than one goal.

What's the difference between a prototype, a proof of concept and an MVP?

A proof of concept tests whether something can be built. A prototype shows how it would look and work, usually without real data. An MVP is used by real people for a real result, so it can tell you whether they want it. With AI tools, the gap between a prototype and an MVP is often small: the difference is real users, real data and a way to pay.

How long should building an MVP take with AI tools?

With AI tools, building the core flow of a focused MVP should take days or weeks, not months. If yours is taking much longer, the scope is usually the problem, not the tools. The longer part should be what comes after: getting it in front of users and learning from them.