How to plan an MVP that actually ships

Most MVPs don't fail because the idea is bad. They fail because the “minimum” quietly grows until it's a full product, the launch date slips, and the money or motivation runs out before a single real user tries it.

An MVP, or minimum viable product, has one job: to find out whether people want what you're building, as cheaply and quickly as possible. Here's the process I use with founders to keep it that way.

1. Write the one-sentence version

Before any feature list, finish this sentence:

“[Who] can [do what] so that [outcome].”

For example: “Food lovers can share and discover dishes from people they trust, so they always know what to order.” If you can't write it in one sentence yet, that's the first thing to work on. Code won't fix it.

2. Find the core loop

Every product has a small loop that users repeat: post, browse, react, come back. That loop is your MVP. For a food-sharing app it might be “post a dish → others see it in their feed → they like or save it.” Everything outside that loop is a candidate for later.

3. List everything, then cut hard

Write down every feature you've imagined. Then sort each one into three columns: must have (the loop doesn't work without it), nice to have and later. Be ruthless. Things that almost always belong in “later”:

• Complex admin dashboards (a simple one, or even a spreadsheet, is fine at first)
• Multiple user roles and permissions
• Detailed analytics beyond a few key events
• Settings screens for things nobody has asked to change yet
• “Scaling to a million users”

4. Choose web or mobile on purpose

A web app is quicker to launch and update, and anyone can try it from a link. A mobile app makes sense when the product lives on the phone: the camera, location, notifications or daily habits. If you're unsure, I wrote about choosing how to build a mobile app.

5. Pick boring technology

Your MVP is not the place to experiment. Proven tools let you move fast and hand the code to a team later. My usual choice is Next.js for the web or React Native for mobile, a managed database such as PostgreSQL or Firebase, and hosted authentication. Nothing exotic, nothing you'll need to rewrite just to grow.

6. Define “done” and what success looks like

Before building, agree on two things:

• Done: the exact list of screens and actions in version one. Anything new goes on the “later” list, not into this release.
• Success: one or two numbers that tell you whether it's working, such as weekly active users, sign-ups that complete the core loop, or people who come back after a week.

7. Build in short cycles you can see

Ask for working software you can click through regularly, not a big reveal at the end. Seeing the product early is how you catch misunderstandings while they're still cheap to fix, and it keeps the scope honest.

8. Launch to real people, then listen

Launch to a small group first: friends of friends, a community or a waitlist. Watch what they actually do, not only what they say. Then decide what to build next from the “later” list, based on evidence.

The common mistakes

• Building for every possible user instead of one clear first audience.
• Polishing features nobody has used yet.
• Skipping the success numbers, so you can't tell whether the MVP worked.
• Choosing tech that only one person can maintain.

Want help scoping yours?

I help founders turn ideas into launched web and mobile apps, from the first scoping session to the App Store. Read about MVP development or tell me about your idea.