What an MVP Actually Is (And Isn't)
A Minimum Viable Product is not a half-finished product, a buggy prototype, or a rushed hack. It's the smallest version of your product that delivers real value to real users and lets you learn something meaningful. The key word is "viable" — it has to actually work for someone.
The goal of an MVP isn't to impress investors or win design awards. It's to answer one question: Will people use this?
Week 1: Ruthless Scoping
Define Your One Core Problem
Write a single sentence: "My product helps [specific person] do [specific thing] so they can [specific outcome]." If you can't fit it in one sentence, your scope is too wide.
List Every Feature — Then Cut 70%
Brainstorm every feature you could build. Then ask for each one: "Can the product survive without this for the first 100 users?" If the answer is yes, cut it. You should end up with a core feature list of 3–5 items maximum.
Choose Your Build Approach
Not every MVP needs custom code. Consider these alternatives based on your goals:
| Approach | Best For | Time to Launch |
|---|---|---|
| No-code (Bubble, Glide, Webflow) | Non-technical founders, fast iteration | 1–2 weeks |
| Concierge MVP | Service-heavy ideas, high-touch validation | Days |
| Wizard of Oz MVP | Automated-feeling service run manually | Days to 1 week |
| Custom code | Technical founders, unique infrastructure needs | 3–6 weeks |
Week 2–3: Build in Sprints
Divide your remaining build time into 3-day sprints. Each sprint should have a clear deliverable — not "work on authentication" but "users can sign up and log in." This keeps momentum high and prevents scope creep.
Build Rules to Live By
- Don't build what you can buy: Use Stripe for payments, Auth0 for auth, Twilio for SMS. Save your energy for your core value prop.
- Make it ugly first: Design polish comes after product-market fit. A functional ugly product beats a beautiful broken one every time.
- Hard-code early decisions: If you're not sure which path to take, hard-code the simplest version and revisit later.
- Ship internally at day 14: Get the first working version in front of 2–3 trusted users at the halfway mark. Their feedback will reshape your final week.
Week 4: Launch and Learn
Recruit Your First 10 Users Manually
Don't wait for organic discovery. Personally reach out to 10 people who fit your target user profile. DM them, email them, or call them. A manual launch forces you to have direct conversations that reveal more than any analytics dashboard.
Instrument Just Enough Analytics
Install one analytics tool (Google Analytics, Plausible, or Mixpanel free tier) and track only two things for now: activation (did they complete the core action?) and retention (did they come back?).
Set Your Learning Goal
Before launch, write down: "After 30 days, I'll consider this MVP a success if ___." Fill in a specific, measurable outcome. This prevents the trap of indefinitely tweaking without ever making a decision.
What Comes After the MVP?
Your MVP launch is the beginning, not the end. After 30 days, you should have real user behavior data. Use it to decide: double down, pivot, or kill. Most successful startups pivot at least once based on what their MVP taught them. That's not failure — that's the process working exactly as it should.