What an MVP is
An MVP (Minimum Viable Product) is the first version of a product with the smallest set of features that solves the users' main problem and shows whether the idea makes sense. It's not a "sloppy" version – it has to work well, just within a narrower scope.
The goal of an MVP is learning: whether users want to use it, what they're willing to pay for and what needs to change. Every further feature should follow from those answers, not from a wish list drawn up before launch.
How to choose features for the first version
1. Name one main problem
Finish the sentence: "The app helps [whom] [do what], because today [what the problem is]". If you need three sentences like that, you probably have three products.
2. Describe the most important user journey
What steps does the user take from opening the app to reaching their goal? E.g. "finds a service → picks a time → pays → gets a confirmation". Everything essential to that journey goes into the MVP.
3. Split the rest into three baskets
- essential – without it the journey doesn't work,
- important, but not for launch – conveniences you'll add after the first feedback,
- nice-to-haves – things that sound good in a meeting but nobody has asked for yet.
4. Replace features with manual processes
At launch, some things can be done by people instead of code: manually approving orders in the panel, a report sent from a spreadsheet, an email reply instead of an automated chat. You automate what has proven itself.
A good check question: "Will the lack of this feature stop the user from reaching their goal?". If not – it's not an MVP feature.
Common pitfalls
- An admin panel "just in case" – elaborate reports and permissions before the first users show up.
- All platforms at once – iOS, Android, web and tablet from day one. Sometimes one platform or a PWA is enough.
- Custom solutions where ready-made ones exist – sign-in, payments, maps, chat.
- No measurement – the app launches, but nobody knows how many people get to the end of the journey.
- An MVP that never ends – the list of "just this one more feature" grows and the launch keeps slipping.
How to prepare a brief for a software house
You don't need a 50-page specification. A good starting brief fits on 1–2 pages:
- who you are and why the product is being built,
- who the app is for and what problem it solves,
- the most important user journey and 3–7 key features,
- platforms – phone, browser, both,
- integrations – systems it needs to connect to,
- what you already have – visual design, wireframes, an existing system, content,
- deadline and budget – even a rough range helps a lot in choosing the scope,
- how you'll measure success – e.g. number of bookings, active users, hours saved.
Based on that, the contractor can propose the MVP scope, technology and schedule – and tell you straight away what's worth postponing.
What to measure after launch
- activation – how many users complete the whole main journey,
- retention – how many come back after a week and after a month,
- drop-off points – at which step users give up,
- feedback – short conversations with the first users tell you more than the best charts.
After a few weeks you have data showing what to invest in for the next version.
How much an MVP costs
An MVP costs a fraction of the full product vision because it covers only what's essential – but it still needs solid design, a backend and testing. We describe the factors that affect the price in the article how much does a mobile app cost.
We help you get from idea to first version: scope workshop, prototype, development and release. See how we build mobile apps and web apps.
Related services: mobile apps, web apps.