A step-by-step guide to building a minimum viable product: testing the riskiest assumption, cutting scope, choosing a stack, measuring results and avoiding common mistakes.
In this article
What an MVP is, and what it is not
A minimum viable product is the smallest version of your product that lets real users get real value, so you can learn whether your idea works. The key word is learn. An MVP is an experiment with a product attached, not a cheaper version of your final vision.
It is also not a broken prototype. Users judge what they see. If the MVP is buggy or confusing, you will not know whether people rejected the idea or the execution. The right MVP is narrow but solid: it does a few things, and it does them well.
Think of three questions your MVP must answer: will the people you are targeting use it, will they come back, and will they pay or show clear signs that they would. Everything in the first release should help answer at least one of those questions.
Start with your riskiest assumption
Every startup idea rests on a few assumptions. Users have this problem. They will pay to solve it. They will switch from what they use today. You can reach them at a reasonable cost. One of these is usually the most uncertain, and if it is wrong, nothing else matters.
Write your assumptions down and pick the riskiest one. Then ask what the cheapest test of that assumption would be. Sometimes the answer is not software at all: a landing page with a waitlist, a WhatsApp group run by hand, or a concierge service where you do the work manually for the first ten customers. Build software when you need software to run the test.
Make the test specific. Instead of asking whether people like the idea, define a measurable signal, such as a set number of businesses signing up for a paid pilot within a fixed period. A clear target turns opinions into a decision.
Cutting scope without cutting value
Scope is where most MVPs go wrong. Founders add features to feel ready, and every feature delays launch and blurs what you are learning. Write user stories for the one core job your product does, then challenge every item on the list.
A useful rule: if a feature does not help a user complete the core job, or does not help you measure whether they did, it waits. Typical items that can wait include the following.
- Multiple login options. Start with one, such as phone OTP or Google.
- Detailed user profiles and settings pages.
- In-app chat, when WhatsApp or email works for now.
- A full admin dashboard. A simple internal panel or even a spreadsheet export is often enough.
- Both mobile platforms at launch, if your early users are mostly on one.
- Advanced analytics dashboards, when a standard analytics tool covers the basics.
- Automation of tasks you can still do by hand at small volume.
Choosing a practical tech stack
Your MVP stack should be boring, well documented and easy to hire for. For mobile, Flutter or React Native lets one team ship Android and iOS from one codebase. For the web, React with Next.js is a common choice. For the backend, Node.js or Python with PostgreSQL covers most needs, and services like Firebase or Supabase can handle login, database and storage so you write less code.
Use proven services for everything that is not your core value: payments through Razorpay or Stripe, email and SMS through established providers, and cloud hosting with managed databases. The aim is to spend your engineering time on the part of the product that is genuinely new.
Do not skip the basics that are painful to add later: source control, a staging environment, automated backups, error tracking and a simple deployment pipeline. These cost little at the start and save a lot once real users arrive.
If you plan to raise funding, investors will likely ask about the tech stack and code ownership. Keep the code in a repository your company owns, document the setup, and avoid niche tools that only one developer knows.
Building in short cycles
Plan the build in one or two week sprints, each ending with something you can click through. Put early versions in front of a handful of target users as soon as the core flow works, even if it is rough around the edges. Watching five people use your product will teach you more than a month of internal debate.
Keep a written list of what you decided not to build and why. It stops the same debates from coming back every week and becomes your roadmap once the MVP proves itself.
Agree on a fixed budget and a target launch date before the build starts, then let scope, not the date, be the thing that flexes. If something takes longer than planned, cut a feature rather than pushing launch back. A launch date that keeps moving is the most common way MVP budgets get out of control.
Measuring what matters after launch
Decide before launch what success looks like. Vanity numbers such as downloads or sign-ups are easy to grow and tell you little. Focus on behaviour that shows real value.
Pair the numbers with conversations. Call users who stayed and users who left, and ask what they were trying to do. The combination of usage data and direct feedback tells you whether to double down, change direction or stop.
- Activation: the share of new users who complete the core job at least once.
- Retention: how many come back after one week and after one month.
- Willingness to pay: pre-orders, paid pilots or conversions from a free trial.
- Referral: whether users bring others without being asked.
Common MVP mistakes to avoid
The most common mistakes are building for too long before showing anyone, building for everyone instead of one clear customer, and treating the MVP code as disposable when it will likely become the foundation of the product. Write it cleanly enough that you can extend it.
Another mistake is ignoring the operational side. Someone needs to answer support messages, process refunds and fix data issues once real users arrive. Plan who does this in the first weeks, even if it is the founders themselves.
Nexzem's MVP engagements usually start with a short discovery workshop to agree on the core job, the riskiest assumption and what will not be built. Whether you work with a partner or build in-house, the discipline is the same: ship something small, learn fast, and let real users shape version two.
