What features should an MVP have? How to find your real first version

What features should an MVP have? Only the ones needed to complete a single loop from start to finish, which is almost always fewer than your list says.

Almost every software idea starts the same way: a long list of everything it could do. That list feels like progress, but it's usually the thing that stalls a project before it starts. The list is too big to price, too big to build, and too big to explain.

The fix isn't to cut features you love. It's to find the one loop your product has to get right, and build only what that loop needs.

That one decision does more for your budget and your timeline than any other choice you'll make. It's also free, and you can do it this afternoon with a piece of paper.

Why a long MVP feature list stalls a project

A twenty-feature list doesn't just cost more to build. It costs more to think about, and that's where projects actually die.

Nobody can price it. Developers quote what they understand. Hand over twenty loosely defined features and you'll get a wide, padded number, because the risk of misreading you is priced in. That's a large part of why quotes vary so much for the same idea.

Nobody can build it in order. With twenty features and no ranking, the build order gets chosen by whoever happens to start, and that's rarely the order that would have got you to a launch soonest.

Nobody can tell what it's for. This is the quiet killer. An app that does five things has no clear first screen and no clear sentence describing it. Users open it, don't understand it, and leave. Nothing about that is fixed by adding feature six.

You can't learn from it. If you launch five half-features and it goes badly, you have no idea which part was wrong. One finished loop that fails tells you something useful. Five partial ones tell you nothing at all.

Find the core loop

Every product has a core loop, the smallest cycle of actions that delivers the value you promise. For a marketplace, it's usually: someone posts a need, someone else answers it, and the two connect. For a booking app, it's: see what's free, pick a time, confirm it.

Write your loop as one sentence. If you can't, that's a sign the idea is still fuzzy, and worth a few more minutes of thinking before anyone writes code.

A good first version does one loop completely, not five loops halfway.

Two rules that make the sentence honest. It has to include the moment the user gets what they came for, not just the moment they finish typing. And it has to be something one person can complete alone, or you've described two loops and you'll need to pick which one to build first.

If you're not yet sure anyone wants the loop at all, don't build it. Test it first, because validating an app idea costs almost nothing compared with building the wrong loop well.

What features should an MVP have? Three examples

Three common products, their loops, and where the line falls. Notice how much sits in Phase 2 without the product being any less ambitious.

The Phase 2 columns are not small. That's the point. Every item in them is a real feature somebody wanted on day one, and none of them stop the loop from working.

Payments are the row worth staring at. Taking money is usually the single most expensive item in a first version, and for plenty of products the first fifty customers can be invoiced by hand while you find out whether the loop works at all.

Everything else is a phase, not a cut

The features you set aside aren't gone. They're Phase 2 and Phase 3. Saying "payments come in Phase 2" is completely different from saying "no payments." It keeps the vision intact while making the first build small enough to actually finish.

This is exactly how a good build plan is structured: a lean Phase 1 that ships, then later phases that add trust, polish, and scale. When you can see your idea laid out that way, it stops feeling overwhelming and starts feeling buildable.

It also changes the conversation with developers. A ranked, phased list is a document someone can price line by line, which is the whole point of briefing a developer properly. An unranked list gets cut by someone who doesn't know your business.

The boring things that belong in Phase 1 anyway

Cutting scope doesn't mean cutting the unglamorous parts. A few things have to be in version one even though no user will ever praise them, and leaving them out is how a launch turns into a rescue.

Accounts, if the loop needs memory. If the app has to remember anything about a person between visits, you need logins in Phase 1. There's no cheap way to add them later.

The empty state. The first thing every new user sees is an app with no data in it. That screen has to explain itself. It's often the highest-value screen in the product and it's usually designed last, if at all.

What happens when things fail. No internet, a declined card, a form submitted twice. You don't need to handle every case beautifully, but the app shouldn't lose someone's work or leave them stuck.

A way to contact a human. Early on, your support channel is your research department. Make it easy to reach you and read everything that arrives.

Those four aren't scope creep. They're the difference between a first version that survives real users and a demo that only works when you're holding it.

A quick test for every MVP feature

For each feature, ask: if this were missing on day one, would the core loop still work? If yes, it's a later phase. If no, it's Phase 1. That single question will shrink most feature lists by half, and make the other half far easier to price and build.

Scoping well isn't about doing less. It's about doing the right less, first.

If the answer is "it would still work, but it'd be embarrassing", that's a Phase 2 item with a note. Write the note. Embarrassment is real feedback and it belongs in the plan, just not in the first build.

What people get wrong about MVPs

Three misreadings do most of the damage.

Thinking it means low quality. It doesn't. It means fewer things, done properly. A rough, buggy version of five features is not a minimum viable product, it's just an unfinished one.

Thinking it's the cheap version of the real thing. It's the first version of the real thing. If you build it as a throwaway, you'll throw it away, and then pay again.

Thinking the cut features are lost. They're scheduled. The founders who scope well aren't the ones who wanted less. They're the ones who wrote down what comes second, so they could stop arguing about it and start building.

The smaller the first version, the sooner real users tell you which of the Phase 2 items actually mattered. Half the time it isn't the one you expected, and finding that out before you paid for it is the entire return on scoping well. A smaller Phase 1 also shortens the calendar, and how long it takes to build an app shows how directly those two move together.

Keep the Phase 2 list somewhere real

The phased approach only works if Phase 2 is a document rather than a promise. Two habits make it stick.

Write it where everyone can see it. A shared list, one line per deferred feature, one sentence on why it waited. Most arguments about scope are really arguments about whether something was forgotten or postponed, and a visible list settles those in seconds.

Add to it instead of arguing. Every good idea that arrives mid-build goes on the list. This is the most useful habit available during a build, because it lets you say yes to the idea and no to the timing in the same breath, and nobody has to feel overruled.

Then, once real users arrive, reorder the list by what they actually ask for instead of what you assumed. That reordering is the most valuable thing your first launch gives you, and it only works if you kept the list.

Decide the loop, then price it

Write your core loop as one sentence today. Put every other feature in a Phase 2 list and stop debating them. That's the whole method, and it's the cheapest thing you'll ever do for the project.

Then find out what the small version actually costs, because a scoped first version is the only thing anyone can quote accurately.

Get an itemized build plan: describe the full idea and get it back as modules and phases, with a lean version one and an estimated total. You keep the ambition. You just build it in an order that finishes.

FAQCommon questions

What should I build first?+

Build the core loop and nothing else. That's the smallest cycle of actions that delivers the value you promised: someone arrives, does the main thing, and gets the result they came for. If a feature isn't needed for that cycle to work end to end, it belongs in a later phase, however much you like it.

How do I know if a feature is Phase 1 or Phase 2?+

Ask whether the core loop still works without it on day one. If yes, it's Phase 2. If the loop breaks, it's Phase 1. This single question usually cuts a feature list in half, and the half that survives is far easier to price, build and explain.

What is a core loop?+

The shortest path a user takes to get value from your product, written as one sentence. For a booking app it's see what's free, pick a time, confirm it. For a marketplace it's someone posts a need, someone answers, the two connect. If you can't write yours in a sentence, the idea needs more thinking before anyone writes code.

How small should an MVP be?+

Small enough that one loop works completely, and no smaller. The common mistake isn't building too little, it's building five features to fifty percent instead of one to a hundred. A first version that does one thing properly gets used. One that does five things partly gets abandoned, and teaches you nothing.

Does cutting features make my app worse?+

It makes the first version smaller, not the product worse. Features you set aside are Phase 2, not deleted, and saying so out loud keeps the vision intact. The apps that fail rarely fail from having too few features. They fail from never launching, or from launching something so unfocused that nobody could tell what it was for.