Most first versions of software try to do too much. The founder or business owner imagines the finished product, lists every feature it might ever need, and asks for all of it. Months later, the product launches into a market that has moved on - or to users who only wanted three of the forty features.
A minimum viable product (MVP) is the antidote. It is the smallest version of your product that solves the core problem well enough for real users to use it and tell you, through their behaviour, whether you are on the right track. This guide explains how to scope one, build it sensibly and learn from it.
What an MVP is - and what it is not
An MVP is:
- Focused on one primary user and one core problem
- Complete enough that users can achieve a real outcome
- Built well enough to be reliable and extended later
- A tool for learning, with clear measures of success
An MVP is not:
- A half-working demo or clickable prototype (that is a prototype - useful, but different)
- A cheap version of the full product with every feature done badly
- Throwaway code you plan to bin after launch
- An excuse to skip security, data protection or basic usability
A good way to think about it: cut the number of features, not the quality of the ones you keep.
Step 1: Define the problem and the user
Write one sentence that describes who has the problem and what it is. For example:
Independent clinics in tier-2 cities lose patients because appointment reminders are sent manually, and often not at all.
Then describe the primary user in detail - their role, their device, their language preference, their comfort with technology and how they solve the problem today. If you cannot describe the user clearly, you are not ready to build.
Step 2: Identify your riskiest assumptions
Every product idea rests on assumptions. List them and mark the ones that would sink the idea if wrong:
- Users actually feel this problem strongly enough to change behaviour.
- They will trust a new tool with their data.
- They are willing to pay, or a business will pay on their behalf.
- The core workflow can be made simple enough on a phone.
- Required integrations (payments, messaging, government APIs) are available.
Your MVP should be designed to test the riskiest assumptions first. Some can be tested even before building - through interviews, landing pages or manual pilots.
Step 3: Map the core user journey
Sketch the single journey the MVP must support end to end. For the clinic example:
- Clinic staff add an appointment.
- The patient receives a confirmation.
- The patient gets a reminder before the appointment.
- The patient confirms or reschedules.
- Staff see the day's confirmed list.
Everything outside this journey is a candidate for later.
Step 4: Prioritise features ruthlessly
List every feature idea, then sort them. An impact-versus-effort view helps:
| | Low effort | High effort |
|---|---|---|
| High impact on core journey | Build first | Build in MVP if essential, otherwise simplify |
| Low impact on core journey | Maybe later, if quick | Postpone |
Typical features that can wait for a second phase: advanced reports, multiple languages beyond the primary one, complex roles and permissions, deep customisation, integrations that are nice but not required, and admin settings that can be handled manually at first.
The "manual first" trick
Many MVP features can be handled by a person behind the scenes at first. Instead of building automated onboarding, your team can set up the first customers manually. Instead of a full billing system, you can raise invoices from your accounting software. Automate once you know the process works.
Step 5: Choose the right format
| Format | Best when | Considerations |
|---|---|---|
| Responsive web app | Users are on desktop and mobile, quick testing needed | No app store approval, works everywhere |
| Progressive web app (PWA) | Mobile-first users, some offline or home-screen use | Install from browser, some device limits |
| Cross-platform mobile app | Need camera, GPS, push notifications, offline use | One codebase for Android and iOS, store review process |
| Native mobile app | Heavy device features or performance needs | Separate builds, more effort |
For many Indian audiences, Android comes first, so test on mid-range Android devices. If the product clearly needs to be an app, our mobile app development team can advise on cross-platform options such as Flutter or React Native.
Step 6: Design just enough
Good design is not optional in an MVP - confused users give you no useful feedback. But design only what the core journey needs:
- Wireframes for each step of the journey
- A simple, consistent visual style
- Clear empty states, error messages and loading states
- Testing the design with a handful of real users before development
A short UI/UX design phase usually saves development time by settling questions on screen rather than in code.
Step 7: Build in short iterations
Break development into short cycles (often one or two weeks), each ending with working software you can see. This lets you:
- Catch misunderstandings early
- Re-prioritise as you learn
- Start testing with internal users before the full MVP is ready
Choose a mainstream, well-supported technology stack - for example Next.js or React with Node.js, or Laravel - so the MVP can grow without a rebuild and other developers can work on it in future.
Step 8: Launch to a small, real audience
Do not launch to everyone at once. Start with a pilot group who match your primary user and are willing to give feedback. Tell them it is an early version and make it easy to report problems - a WhatsApp number or in-app feedback button works well.
Step 9: Measure, learn and decide
Before launch, agree what success looks like. Useful MVP measures include:
- How many pilot users complete the core journey
- How many come back and use it again
- Where they get stuck or drop off
- What they ask for most often
- Whether they would pay, or recommend it
After a few weeks of use, decide: continue (improve and add the next priority features), change direction (the problem is real but the solution needs rethinking) or stop (the assumption was wrong - a cheaper lesson now than later).
MVPs for internal business tools
MVP thinking is not only for start-ups. If you are replacing spreadsheets with an internal system - for orders, field service, inventory or approvals - the same approach applies:
- Pick one department or one process to digitise first, such as order entry, rather than the whole company.
- Run the new system alongside the old method for a short period so nothing is lost while people learn.
- Choose a few champions in the team who give feedback and help colleagues.
- Expand to the next process only when the first one is working smoothly and people prefer it.
This lowers risk, gets value into the business sooner and builds trust in the new software.
What a typical MVP plan looks like
| Phase | Main activities | Output |
|---|---|---|
| Discovery | Problem statement, user interviews, riskiest assumptions | Agreed scope and success measures |
| Design | Core journey wireframes, user testing | Approved screens |
| Build | Short development cycles with regular demos | Working, tested software |
| Pilot | Small group of real users, feedback channel | Usage data and feedback |
| Review | Compare results with success measures | Decision on next phase |
Common MVP mistakes
- Building for everyone. Trying to serve every user type dilutes the core experience.
- Skipping the basics. Weak security, no backups or ignoring personal data obligations under the Digital Personal Data Protection Act, 2023 are not acceptable shortcuts.
- No success measures. Without them, every result looks like "promising".
- Adding features instead of fixing the journey. If users drop off, find out why before building more.
- Waiting for perfection. An MVP that is never released teaches nothing.
Key takeaways
- An MVP is the smallest version that solves the core problem well - fewer features, not lower quality.
- Start with a clear problem statement, a primary user and your riskiest assumptions.
- Map one core journey and postpone everything outside it.
- Choose the format (web, PWA or app) based on how users will really use it.
- Launch to a small group, measure what matters and decide the next step with data.
Turn your idea into a focused first version
Scoping is where MVPs succeed or fail. In a free consultation, our 25+ member in-house team in Jaipur helps you define the core journey, identify what can wait and choose the right format, then sends a phased plan and a written quote. Explore our custom software development services.
