TL;DR
A well-planned MVP takes 4–8 weeks to define clearly before a single line of code is written. The planning process involves: validating your assumptions, defining one core problem and one core solution, writing user stories (not feature lists), choosing a tech stack aligned to your team’s skills, and scoping ruthlessly until you have the smallest thing that can teach you something real.
What Makes a Good MVP
An MVP is not a rough version of your product. It’s a focused version — built to answer a specific question: “Will people use this and pay for it?”
A good MVP has:
- One user type — not all possible users
- One core workflow — the thing that delivers the main value
- Real users — not friends or family
- A way to measure success — signups, activations, retention, revenue
A bad MVP has:
- Too many features (“just in case users want it”)
- No clear success metric
- Users who are too polite to give honest feedback
- A 12-month build timeline before anything ships
Step 1: Validate Before You Build
The hardest thing to hear: you don’t need to build anything to validate your idea.
Before writing a line of code:
Talk to 20 potential users. Not “would you use this?” (everyone says yes). Ask: “Tell me about the last time you had this problem. What did you do about it? How much did it cost you in time or money?”
Test demand manually. Build a landing page with a Stripe payment link. If people won’t pay $X before the product exists, they probably won’t after it’s built.
Find the painful problem. The best MVPs solve a problem people hate enough to pay to fix today. If users are “interested” but not urgently motivated, you don’t have a business yet.
Step 2: Define the Core Problem and Solution
Write one sentence for each:
Problem: [User type] struggles with [specific problem] because [underlying reason], which costs them [time/money/frustration].
Solution: [Product name] lets [user type] [do the core thing] so that [outcome].
If you can’t write these sentences clearly, your product isn’t defined well enough to build.
Step 3: Write User Stories, Not a Feature List
User stories force you to think about what users actually need, not what features sound impressive:
- “As a [user], I want to [do something] so that [benefit].”
Example for a project management tool:
- “As a project manager, I want to create a task with a deadline so that my team knows what to work on first.”
- “As a team member, I want to mark a task complete so that my manager can see progress.”
From these, extract only the stories that enable the absolute core workflow. Everything else is v2.
Step 4: Ruthless Scope Reduction
For every proposed feature, ask: “Can we launch and learn without this?”
Features that almost never belong in an MVP:
- Mobile app (build web first)
- Advanced notifications / email automation
- Admin analytics dashboard
- Third-party integrations (Zapier, Slack, etc.)
- Team / multi-user features (unless the product is inherently collaborative)
- A public API
- Dark mode
Features that almost always belong in an MVP:
- Auth (sign up, log in, password reset)
- The one core workflow
- Basic data persistence
- A way to collect payment (even if it’s manual at first)
- A way to contact users (email or in-app)
Step 5: Choose Your Tech Stack
The best tech stack is the one your team knows best. Don’t introduce new technologies in an MVP — learning curves slow you down when speed is everything.
A standard, proven MVP stack in 2026:
- Frontend: Next.js (React) — fast, deployable on Vercel in minutes
- Database: Supabase (Postgres) or PlanetScale — managed, scalable
- Auth: Clerk or Supabase Auth — days to implement, not weeks
- Payments: Stripe — the only reasonable choice
- Deployment: Vercel + GitHub — zero-config CI/CD
- Email: Resend — simple transactional email API
This stack lets a solo developer ship a working MVP in 4–8 weeks.
Step 6: Set a Hard Launch Date
Without a deadline, MVPs expand forever. Set a date — typically 6–10 weeks from kick-off — and treat it as immovable. Any feature that can’t be built by that date is cut from v1.
The goal of the deadline isn’t polish. It’s momentum. Every week you’re not shipping, a competitor is.
Step 7: Define Success Before You Build
Before writing code, write down:
- Primary metric: The one number that tells you if the MVP is working (usually: daily active users, or revenue, or activation rate)
- Success threshold: “If [X] users use the core feature [Y] times in [Z] weeks, we keep building”
- Failure criteria: “If [threshold] isn’t met by [date], we pivot or stop”
Having these defined in advance prevents post-launch rationalisations.
Frequently Asked Questions
How many features should an MVP have?
As few as possible. Typically 1 core feature + supporting infrastructure (auth, billing, profile management). If your MVP feature list has more than 10 items, it needs more cutting.
Should I build iOS and Android for my MVP?
No. Build a mobile-responsive web app first. Native apps cost 3–5x more and take longer to launch. Only build native apps when you have evidence that your core users need native features (camera, push notifications, offline mode).
How do I know when my MVP is ready to launch?
When the core workflow works end-to-end for a user who has never seen the product before. Not when it’s polished. Not when every edge case is handled. When it works.
How long should the MVP phase last?
3–6 months post-launch. In that time, you should have enough user data to make a clear decision: double down, pivot, or stop.
Final Thoughts
The best MVPs ship fast, learn faster, and treat code as a means to an end — not the product itself. Build the minimum. Ship it. Talk to users. Repeat.
If you need help scoping and building your MVP, we do this every week.