Most of the app ideas that reach us don’t die because they were bad. They die because they tried to do everything at once. The feature list balloons, the budget runs dry before the first release, and after a year of work there’s still nothing in the store. This lesson is about the opposite: how to cut an idea down to a first version worth shipping, and only then let it grow based on what people actually do.
What an MVP is, and why not “everything at once”
An MVP is the smallest version of an app that delivers the one core value and is already worth releasing. Not a half-finished thing, not “almost done.” Something a real user opens and gets exactly what they downloaded the app for.
The temptation to build everything first is enormous, because on paper every feature looks important. But every feature is work: you have to design it, code it, test it, and then maintain it forever. If you want everything finished before the first release, you reach the point where you’ve spent the whole budget on things you have no idea anyone even wants.
An MVP hurts. You’ll ship something you’re a little embarrassed by, and you’ll have to turn down features you love. But that’s the only way to learn what to build next, before you’ve spent everything.
And above all: until someone is actually using the app, all your ideas about what people want are just guesses. An MVP turns those guesses into data.
Must-have vs nice-to-have: how to sort your features
Go back to the one core job the app is meant to do (we covered it in the first lesson). Then run every feature through a single question: does this thing help the user get that one core job done, or do they manage the job just fine without it?
- Must-have. Without this feature the app doesn’t deliver its value. Cut it and the app loses its point. This goes into v1.
- Nice-to-have. Nice, useful, but the core job works without it. This waits for v2, v3, or never.
Take an app for booking a table at a restaurant. Picking a time and sending the reservation is must-have. Filtering by cuisine, loyalty points, sharing a booking with friends, and dark mode are nice-to-have. Lovely ideas, but not one of them is the reason someone downloaded the app.
Watch out for “and.” When you describe the app and say “it’s for reservations and also ordering food and reviews too,” every “and” is a sign you’re cramming several projects into v1 at once. One app, one core job. The rest is a wish list.
The critical user path: build it first, and build it well
Before you build anything, draw a single path: step by step, what the user does from opening the app to the moment they get their value. For the booking app, say: open the app → pick a restaurant → choose a date and party size → confirm → see the booking confirmation. Five steps. That’s your critical path.
This path has to work brilliantly in the MVP. Not “somehow.” Brilliantly. Fast, clear, no snags. It’s the part people will judge you on and the reason they come back, or delete the app.
Everything else in the first version can be plain, and that’s fine. Account settings don’t need ten toggles; one will do. The profile doesn’t need to be polished to a shine. But that one path the app exists for has to be buffed until it gleams. When you’re not sure where to put your energy, put it here.
A clickable prototype before the first line of code
This is where you can save the most money, and almost nobody does it. Before anyone starts coding, build a clickable prototype: screens mocked up in Figma or a similar tool, linked together so you can actually click through the critical path on a phone.
The reason is simple and very practical: changing a screen in a prototype takes five minutes. Changing it in a coded app takes days and costs money. The sooner you discover you put a button in a dumb place or that an extra step confuses people, the cheaper it is to fix.
- Hand the prototype to five people. Ideally ones who don’t know the app. Stay quiet and watch where they hesitate. Wherever they ask “okay, now what?”, you’ve got a problem.
- Don’t fuss over colors and icons. In a prototype, the point is whether the path makes sense, not whether the blue is the right blue.
- Only once the path holds up do you start coding. A prototype that five people got through without hesitating is the cheapest insurance you can buy.
The common traps almost everyone falls into
An app idea has a few classic ways to kill itself. These are the ones we run into over and over:
- Feature creep. The feature list grows faster than you can build. Every week brings another “it’d be nice if it also…” The cure is that one sentence about the core job: if a new feature doesn’t serve that sentence, it goes on the later list, not into v1.
- Copying the big apps. Instagram, Uber, or Booking have hundreds of people and years of work behind them. What you see in them is the result of a decade, not their MVP. Copying today’s Instagram as your first version is like building a highway before you know whether anyone will drive on it.
- Polishing things nobody uses. Three days spent on a settings screen that two percent of people will ever open in their lifetime. Or ten theme variants when most users leave the default. Put the energy into the critical path, not into the corners nobody visits.
Write down one sentence and keep it somewhere safe: “The first version of our app has to do (what) for (whom), and nothing more.” Every time a new feature idea comes up, go back to it. If the idea doesn’t serve that sentence, it doesn’t belong in v1.
An MVP isn’t about doing little. It’s about doing the right thing first, and doing it well. Once people are actually using that one thing, they’ll tell you what to build next themselves. And that’s a far better brief than any list you dream up at a desk beforehand.