What Should Your MVP Actually Include? (And What to Cut Ruthlessly)

You have a list of 30 features and you're convinced every single one is essential. I know because I've sat across from founders who say "but users will expect this" about a feature that won't matter for another six months. The hardest part of building an MVP isn't the building. It's deciding what not to build.

After six years of shipping MVPs for non-technical founders, I can tell you: the features you cut matter more than the features you keep. Here's how to figure out what stays, what goes, and how to stop lying to yourself about what's "essential."

The Only Question That Matters

Before you touch a features list, answer this: What is the one thing your product must do for a user to get value from it?

Not three things. Not five. One.

If you can't answer that in a single sentence, you're not ready to build. You're still exploring an idea, and that's fine — but don't spend money on development yet.

I built Prettan ERP for a Mexican supplement manufacturer. They came to me with a wish list: invoicing, inventory management, production tracking, supplier portals, a full reporting dashboard. We cut everything except invoicing. Why? Their actual daily pain was manual invoice generation. Everything else was a "would be nice" dressed up as a "must have."

Six weeks later they had a working invoicing system. The reporting module they were so passionate about? They never asked for it again.

How to Build Your MVP Features List

Here's the process I walk founders through. Not glamorous, but it works.

Step 1: Write Down Everything

Get every feature out of your head and onto paper. Don't filter yet. Include the wild ideas, the "phase 3" stuff, all of it. You need to see the full scope so you can confront it honestly.

Step 2: Sort Into Three Buckets

• Must have — The product literally doesn't work without this. Users can't complete the core action.
• Should have — Improves the experience but users can still get value without it.
• Nice to have — You want it because a competitor has it, or because it sounds impressive in a pitch deck.

Now the uncomfortable part: go back to your "must have" list and cut it in half. I'm serious. At least half of what you labeled as essential isn't. You're emotionally attached to features that don't serve your first ten users.

Step 3: Validate With Real Humans

Show your stripped-down concept to five people who match your target user. Not your friends. Not your co-founder. People who would actually pay for this.

Ask them: "Would you use this if it only did X?" If yes, you've found your MVP. If "only if it also does Y," then maybe Y belongs in the build. But be skeptical — people love adding requirements in hypothetical conversations that they'd never care about in practice.

What You Should Almost Always Cut

I see the same features get cut over and over. Here's what to leave out by default.

Admin dashboards with analytics. You don't need charts and graphs at launch. You need a database you can query. Dashboards are for when you have enough users to make the data meaningful.

User-to-user messaging or live chat. I rebuilt CherryStripes, a women's wellness app, from scratch in six weeks. The previous version had live chat. The first 20 real users didn't care about it — we cut it. What they did ask for was a "challenge a friend" feature nobody had planned. That one addition took the app from 20 to 100+ users in three weeks.

Your users define the right MVP. Not your assumptions.

Complex onboarding flows. A simple sign-up form beats an 8-step wizard. Optimize onboarding once you understand where users actually drop off.

Multiple user roles and permissions. Start with one user type. Add roles when your user base actually needs them.

Integrations with every platform. Pick the one integration that matters most. For Paws Art AI, we built third-party integrations from day one — but only the ones that directly affected revenue. Everything else waited.

The Real Risk Isn't Building Too Little

Founders worry about launching something too small. That it'll look "unprofessional" or disappoint users. But I've never seen an MVP fail because it had too few features. I've seen plenty fail because they took too long to build, ran out of money before launch, or were so bloated that nobody understood what the product actually did.

The Draft Order App I built was a simple web app for managing fantasy league draft orders and tracking payments. Two weeks. No social features, no league history archives, no notification system. Just the core job done well. It worked because the scope was honest.

Your MVP is not your final product. It's a test. You're spending the minimum time and money to learn whether your idea solves a real problem for real people.

If you treat it like a test, you'll cut the reporting dashboard. You'll skip the custom notification preferences. You'll launch in weeks instead of months.

Then your users tell you what to build next. Not your roadmap. Not your competitor's feature page. The people actually using your product.

Stop agonizing over the perfect features list. Build the smallest thing that delivers value, ship it, and listen.

Not sure which path is right for your project? Describe your idea and I'll give you my honest take — no sales pitch. Get in touch