A minimum viable product is the smallest version of a product that lets real users get real value, so you can learn whether the idea works before spending the full budget. In practice many MVPs are neither minimum nor viable. They take nine months, include an admin panel with forty settings, and launch to an audience nobody talked to first. Here is how we help founders and internal teams keep an MVP small enough to ship and useful enough to learn from.
Start With One Problem and One Number
Write down, in one sentence, who the product is for and the problem it solves for them. Then choose the single number that will tell you whether it works. For a booking app it might be the share of users who make a second booking within a month. For an internal tool it might be the hours saved per week. Every feature request gets measured against that sentence and that number. If a feature does not move the number, it waits.
Test the Idea Before Writing Code
- Talk to ten to twenty people who have the problem and ask how they handle it today and what it costs them.
- Show a clickable prototype in Figma and watch where people get stuck.
- Put up a landing page with a waiting list or pre-order button to see if anyone signs up.
- Run the service by hand for the first few customers, with spreadsheets and WhatsApp, to learn the real workflow.
These steps take days and cost little. They often change the scope of the MVP more than any technical decision.
Cut the Feature List Hard
| Category | Examples | In the MVP? |
|---|---|---|
| Core flow | The steps a user takes to get the main value, such as search, book, and pay | Yes, and done well |
| Basic trust and safety | Login, password reset, data backups, HTTPS, basic access control | Yes, these are hard to add later |
| Operations | Admin screens to fix data and help customers | A simple version, or edit records directly at first |
| Growth features | Referrals, loyalty points, recommendations | After you see people using the core flow |
| Polish and edge cases | Dark mode, many languages, rare payment methods | Later, based on what users ask for |
A useful exercise is to ask what would happen if a feature were missing on launch day. If the honest answer is that a few users would be mildly annoyed, it does not belong in the MVP.
Choose a Stack You Can Keep
Minimum does not mean throwaway. If the MVP works, it usually becomes the product, so build it on mainstream technology your future team can hire for. A web app with Next.js or Laravel, a cross-platform mobile app with Flutter if you need one, a managed database such as PostgreSQL, and a hosted payment gateway cover most cases. Avoid microservices, Kubernetes, and custom infrastructure at this stage. Use ready services for email, payments, maps, and authentication instead of building them.
Set a Realistic Timeline
For a focused MVP with one main user flow, a small team of two to four people can often reach a first release in eight to twelve weeks. Projects that run much longer usually have a scope problem. Plan in short iterations of one or two weeks, demo working software at the end of each, and keep a fixed launch date while letting the feature list shrink if needed.
- 1Week 1 to 2: confirm scope, user flows, and designs for the core screens.
- 2Week 3 to 8: build the core flow end to end first, then the supporting features, with a staging environment from the start.
- 3Week 9 to 10: test with a small group of real users and fix what blocks them.
- 4Week 11 to 12: launch to a wider group, with analytics and error monitoring in place.
Measure What Users Actually Do
Add product analytics such as PostHog or Google Analytics events for each step of the core flow, so you can see where users drop off. Add error tracking such as Sentry so crashes reach you before complaints do. Then talk to users every week. Numbers show what happened, and conversations explain why.
Decide What Comes Next
- If the key number is improving, invest in the features users keep asking for and in the technical debt that slows the team.
- If people sign up but do not come back, the core flow is not solving the problem well enough. Fix that before adding features.
- If almost nobody signs up, revisit the problem or the audience. More features rarely fix a demand problem.
The goal of an MVP is learning. Launching is only the moment the learning starts.
Make sure you own the source code, the cloud accounts, and the domain from the start, whoever builds the MVP. We build MVPs for startups and companies with a small dedicated team, weekly demos, and full handover of code and infrastructure.
Key takeaways
- Define one user, one problem, and one number that shows whether the MVP works.
- Validate with interviews, prototypes, and manual service before writing code.
- Keep the core flow and basic security, and push growth features and polish to later.
- Build on mainstream technology and managed services, since a successful MVP becomes the product.
- Plan around eight to twelve weeks for a focused MVP, and shrink scope before moving the date.
