What Is an MVP? How to Build a Product That Ships in 8 Weeks
An MVP is not a cheap version of your product; it is the version that tests your riskiest assumption fastest. Knowing that difference is the difference between months of wasted building and getting to market early.
MVP (Minimum Viable Product) is one of the most misread terms around. Most people take it as “a first version with few features and low quality”. Here is the accurate reading: an MVP is the version that lets you test the riskiest assumption about your product with the least effort.
What an MVP is not
- It is not a half-finished product. It does few things, but it does them properly.
- It is not a prototype. A prototype is clicked through; an MVP is used and produces real data.
- It is not design-free. A poor interface stops you from telling whether the idea or the experience was rejected.
- It is not throwaway code. Code written to be thrown away is usually still in production three years later.
A practical method for cutting scope
Shortening the feature list is the part everyone finds hard, because every item feels valuable to someone. We work through it with three questions.
1. A one-sentence definition of success
“This version counts as successful if ___.” Fill the blank with something measurable: “20 businesses upload their own catalogue and receive their first order”, for instance. Every feature that does not serve that sentence goes on the v2 list.
2. One critical user journey
Which path is the one where the user feels the value for the first time? Sign-up → setup → first result. Every step of that journey has to be flawless; every screen outside it can wait.
3. The “could a human do it?” test
If you can do a job by hand in the background for the first 50 users, do not code it. Generating invoices, granting approvals, moderating content — in a first version these can often run on people. Automation comes after demand is proven.
A realistic 8-week roadmap
| Week | Focus | Output |
|---|---|---|
| 1 | Discovery and scope | Definition of success, user journey, screen list |
| 2 | Design | Clickable prototype, core of the design system |
| 3 | Foundations | Data model, authentication, deployment pipeline |
| 4–5 | Main flow | The critical journey working end to end |
| 6 | Side flows | Admin screen, notifications, empty/error states |
| 7 | Hardening | Testing, performance, security review |
| 8 | Launch | Production environment, measurement, first users |
5 mistakes that sink an MVP
- Launching without measurement. If you do not know who signed up, where they got stuck and on which screen they gave up, you cannot learn.
- Copying a competitor's feature list. Their three-year-old product is not a roadmap for your eight-week one.
- Over-investing in the admin panel in v1. In the first months, looking directly at the database is usually enough.
- Taking on personalisation, multiple languages and theming early. These make sense after the product lands.
- Not setting up a feedback channel. An MVP whose first users are never spoken to is just an expensive guess.
The right stack for an MVP
At MVP stage there is only one criterion for technology choice: the team being able to move fast. Buying complexity today for a “what if we get a million users” scenario runs against the whole point of an MVP.
| Layer | Sensible choice for an MVP | Why |
|---|---|---|
| Web interface | Next.js + TypeScript | Pages, API and SEO under one roof |
| Mobile | React Native + Expo | One codebase, fast store distribution |
| Database + identity | Postgres (Supabase) | Auth, storage and permissions come ready |
| Payments | An existing provider integration | Do not write your own payment infrastructure |
| Deployment | A managed platform (Vercel, Cloudflare) | Ship without managing servers |
| Measurement | Lightweight analytics + error tracking | Start collecting data from day one |
What this stack has in common: none of it locks you in. Once user numbers and revenue are real, each layer can be replaced on its own. Instead of optimising early, protect your ability to change.
A simple way to plan the MVP budget
An MVP budget is not a single line. In practice, splitting it three ways works:
- 70% — development and design. The product itself.
- 20% — the first two months after launch. Bug fixing and small changes based on user feedback. Without this money, the MVP freezes on the day it ships.
- 10% — measurement and learning. Analytics setup, user interviews, small experiments.
What happens after launch?
An MVP is not an ending; it is the start of measurement. In the first two weeks you look at three things: how many people completed the critical journey, where they dropped off, and whether they came back and used it again. Those three data points write the v2 scope for you.
If you want to turn your idea into an 8-week plan, tell us about it briefly. In the first call we cut the scope together — that usually turns out to be the most valuable part.
Frequently asked questions
How long does it take to build an MVP?
A well-trimmed MVP typically ships in 6–10 weeks. What sets the timeline is decision speed more than feature count: if the scope is clear and there is a single decision-maker, 8 weeks is a realistic target.
What is the difference between an MVP and a prototype?
A prototype is a clickable draft; it does not process real data and is not offered to users. An MVP is a product running in a production environment, used by real users and producing measurable data.
Can design be compromised in an MVP?
No. A poor interface stops you from telling whether users rejected the idea or the experience, and it contaminates the result of the test. An MVP has few screens, but the screens it has must be done with care.