What an MVP is — and isn’t
A minimum viable product is the smallest version of your product that solves one real problem for real users. Minimum means few features. Viable means those features work properly, so people can rely on them.
| An MVP is | An MVP is not |
|---|---|
| Focused on one main job | Every feature, built badly |
| Used by real customers or staff | A clickable demo nobody uses |
| Built to learn what to do next | The final product |
| Polished where users touch it | Buggy because “it’s only an MVP” |
Start with one sentence
Before writing any feature list, write this sentence — and don’t move on until it is sharp:
Here is an example for a gym: “For our members, the app lets them renew their plan and book a trainer slot, so that renewals don’t depend on the front desk. It works if 40% of renewals happen in the app within three months.”
Map the one journey that matters
Write down, step by step, what a user does from start to finish to get that one job done. For the gym: open the app → sign in with a phone number → see plan and expiry → pay by UPI → get a receipt → book a slot.
Every screen and feature in the MVP should serve a step on that path. Anything that doesn’t is a candidate for “later”.
Sort features into must-have, later and never
| Feature (gym example) | Decision | Why |
|---|---|---|
| Sign in with phone and OTP | Must-have | Members need an account to renew. |
| Plan and expiry date | Must-have | It’s the reason members open the app. |
| Pay by UPI or card | Must-have | The main job is renewal. |
| Book a trainer slot | Must-have | It’s part of the one sentence. |
| Simple admin list of renewals | Must-have | The owner needs to see results — a list is enough at first. |
| Workout tracking | Later | Useful, but not why members first open the app. |
| Diet plans | Later | Valuable, but a whole product of its own. |
| Social feed and leaderboards | Never, for now | Hard to do well, and demand is unproven. |
Do things by hand at first
Not everything needs to be automated on day one. Many successful products started with a person quietly doing part of the work behind the scenes:
- Send reminders by hand from a list the app generates, before building automated WhatsApp flows.
- Approve new accounts manually before building complex verification.
- Export a spreadsheet each week instead of building a full reporting dashboard.
Manual steps are cheap to try, and they teach you exactly what the automated version needs to do.
Build, launch and measure
- 01
Design the key screens first
Agree how the main journey looks before building. Changing a design is much quicker than changing code.
- 02
Build in short sprints with a live preview
See working software every week or two, and correct course early.
- 03
Launch to a small group
Start with friendly customers or one branch, and watch how they use it.
- 04
Measure the number you chose
Compare it with your one sentence. Talk to users who stopped halfway.
- 05
Decide what comes next
Improve the main journey, add a “later” feature, or change direction — based on evidence, not guesses.
Wondering whether your first version should be a website or an app? Read web app vs mobile app vs PWA.
Common MVP mistakes
- Building for every user type at once. Start with the one group whose problem is sharpest.
- Skipping the admin side. Someone has to run the product. Keep admin tools simple, but don’t skip them.
- Low quality in the core journey. If paying or booking is buggy, users won’t come back to see the rest.
- No way to measure. Without basic analytics — or at least a count in the database — you won’t know whether it works.
- Treating launch as the finish line. The MVP is where learning starts. Keep budget for the changes that follow.
Questions people ask
- How long does it take to build an MVP?
- A focused web MVP often takes a few weeks to around three months, depending on integrations and how quickly decisions are made. The tighter the scope, the faster the launch.
- Should my MVP be a web app or a mobile app?
- Usually a web app, because it is faster to build and update. Choose mobile first only if daily use, reliable notifications or phone hardware are central to the idea.
- Can an MVP grow into the full product?
- Yes, if it is built properly. An MVP should be small in scope, not low in quality, so the same codebase can grow as you add features.
- Do I need investors before building an MVP?
- No. Many businesses fund a focused MVP themselves, precisely because it is small. A working product with real users is also far more convincing to investors than slides.
Planning something like this?
Tell us what you want to build. You’ll get a written scope and a fixed quote before any work starts.