A founder came to us with a 47-page feature spec for a "comprehensive project management platform." We convinced them to launch with one feature: a shared task list with real-time updates. That single feature validated that teams would actually pay for their specific workflow angle. Three months later, they raised seed funding based on 200 paying users — all acquired through that stripped-down MVP. The 47-page spec? Most of it never got built. The market wanted something different than what the founder imagined.
What We'll Cover
What an MVP Actually Is
An MVP is the smallest product that lets you test your riskiest assumption. It's not a prototype (that tests feasibility). It's not a beta (that tests quality). It's an experiment that answers: "Will people pay for this?"
| MVP Is | MVP Is NOT |
|---|---|
| One core feature done well | A half-finished version of the full product |
| Enough to test a specific hypothesis | Everything you could possibly build |
| Usable by real users (even if rough) | An internal demo or clickable mockup |
| Built to learn what to build next | Built to impress investors |
| Weeks to build, not months | A 6-month project with "just the basics" |
The biggest MVP mistake: building features nobody asked for. Every feature you add before launch is a guess. Ship fast, get feedback, then decide what to build next.
Validate Before You Write Code
70% of the MVPs we've built that failed did so for the same reason: the market didn't want the product. Not because of bugs, not bad design — just wrong product. Validation before coding saves months of wasted effort.
Validation Techniques (Ordered by Effort)
| Technique | Effort | What It Validates | Watch Out For |
|---|---|---|---|
| Landing page + waitlist | 1-2 days | Is there interest? Will people give you their email? | Email signups ≠ willingness to pay. Still useful for gauging interest |
| Problem interviews (10-15 people) | 1 week | Does the problem exist? How painful is it? What do they do today? | People say "I'd use that!" but won't pay. Ask about current behavior, not future intent |
| Concierge MVP | 1-2 weeks | Will people pay for the solution? (You deliver manually) | Doesn't validate scalability. But validates demand with zero code |
| Wizard of Oz MVP | 2-3 weeks | Will people use the product interface? (Looks automated, human-powered behind scenes) | Expensive to maintain. Use only to validate UX, then automate |
| Coded MVP | 4-8 weeks | Full hypothesis: demand + willingness to pay + usability | Only build this after landing page or interviews show clear signal |
Technology Choices for MVPs
For MVPs, speed of development beats everything else. The "best" technology is the one your team ships fastest in. Don't learn a new framework for an MVP. For a full guide on choosing your startup's tech stack, see our dedicated article.
Our MVP Tech Stack Recommendations
| MVP Type | Recommended Stack | Why | Timeline |
|---|---|---|---|
| B2B SaaS | Next.js + Supabase + Vercel | Auth, database, hosting all handled. Focus on business logic | 4-6 weeks |
| Marketplace | Next.js + PostgreSQL + Stripe Connect | Payments between buyers/sellers built-in. Critical path handled | 6-8 weeks |
| Mobile-first app | React Native or Flutter + Firebase | Cross-platform from day one. Firebase handles auth, push notifications, analytics | 6-8 weeks |
| AI/ML product | Next.js + Python API + OpenAI/Claude API | Use existing LLMs before building custom models. Validate the use case first | 3-5 weeks |
| Internal tool | Retool or Budibase + existing database | No-code/low-code for internal tools. Build in days, not weeks | 1-2 weeks |
What NOT to Do in an MVP
- Don't build a custom auth system. Use Supabase Auth, Firebase Auth, or Clerk. Auth is not your differentiator
- Don't optimize for scale. If you get 10,000 users on day one, that's a great problem to have later. Build for 100 users now
- Don't build an admin panel. Use the database directly or a tool like Retool. Admin panels are time sinks
- Don't support multiple payment providers. Stripe. Done. Add alternatives when revenue justifies it
- Don't write microservices. A monolith is faster to build, deploy, and debug. Split later when you have clear scaling needs
The MVP Build Process
Week 1: Define and Design
- Write the one-sentence hypothesis: "We believe [target user] will [action] because [reason]"
- List every feature you want. Now cut 80% of them. The remaining 20% is your MVP
- Design the core user flow (3-5 screens). Use Figma or even paper sketches. Don't design the whole app
- Define your success metric: "MVP is successful if X users do Y within Z days"
Weeks 2-5: Build
- Sprint 1: Core flow end-to-end (even if ugly). User can complete the primary action
- Sprint 2: Payment integration (if charging) and basic error handling
- Sprint 3: Polish the happy path. Fix the top 5 UX issues from internal testing
Week 6: Launch Prep
- Basic analytics (Mixpanel, PostHog, or even just Google Analytics events)
- Error monitoring (Sentry — free tier is enough)
- Transactional emails (Resend or SendGrid free tier)
- Landing page with clear value proposition and signup flow
Launch and First Users
Launching an MVP is not a Product Hunt launch or a press release. It's putting the product in front of 20-50 target users and watching what happens.
Where to Find First Users
- Your interview list. The 10-15 people you talked to during validation. They already have the problem
- Niche communities. Slack groups, Discord servers, subreddits related to your problem space
- Personal network. Ask for introductions to people who fit your target user profile
- Cold outreach (LinkedIn, email) to people who match your ICP. 2-3% response rate is normal
What to Watch After Launch
- Activation rate: % of signups who complete the core action. Below 30%? Your onboarding is broken
- Retention: Do users come back? Day 1, Day 7, Day 30 retention. This is the most important metric
- Qualitative feedback: Talk to every user. Ask "What's confusing?" and "What's missing?" — not "Do you like it?"
Iterating to Product-Market Fit
Product-market fit is when users would be "very disappointed" if your product disappeared. Sean Ellis' survey: if 40%+ of users say "very disappointed," you have PMF.
The Iteration Loop
- Ship the smallest change that addresses the top user complaint
- Measure whether it moves your core metric (retention, activation, NPS)
- Learn from the data + user conversations. Adjust your hypothesis
- Repeat every 1-2 weeks
When to Pivot vs. Persevere
| Signal | Action |
|---|---|
| Users sign up but don't activate | Fix onboarding. The product might be fine; the first experience isn't |
| Users activate but don't retain | The core value isn't strong enough. Talk to churned users |
| Users retain but won't pay | Price or packaging issue. Experiment with pricing tiers |
| Nobody signs up despite marketing | Problem isn't painful enough, or messaging doesn't resonate. Re-validate |
| Users love it and tell others organically | You've found PMF. Stop iterating on the core — scale growth and reliability |
Cost Reality Check
Here's what MVP development actually costs in India (2025-2026 rates):
- Solo developer (freelance): ₹3-8 lakh for 6-8 weeks
- Development agency (like us): ₹8-20 lakh for 6-8 weeks (includes design, dev, and QA)
- In-house team (2 devs + 1 designer): ₹4-6 lakh/month salary cost
- No-code (Bubble, Webflow): ₹50K-2 lakh (platform + contractor)
Infrastructure costs for an MVP are nearly zero: Vercel free tier, Supabase free tier, Sentry free tier, and Stripe's only charge is a percentage of transactions. You can run an MVP for under ₹5,000/month in hosting.
Frequently Asked Questions
How long should it take to build an MVP?
4-8 weeks for a coded MVP. If it's taking longer than 8 weeks, you're building too much. Cut features ruthlessly. The goal is to learn, not to launch a polished product. A concierge or landing page MVP can be done in 1-2 weeks.
Should I use no-code tools for my MVP?
If your MVP is a form-based workflow, content platform, or marketplace with standard flows — yes. No-code tools like Bubble can save weeks. If your MVP requires custom real-time features, complex integrations, or AI/ML — code is faster because no-code tools hit walls quickly on non-standard requirements.
How do I know when to stop adding features to my MVP?
When a user can complete the core action end-to-end — sign up, do the main thing, and (if applicable) pay. Everything else is a post-launch iteration. If you're debating whether to add a feature, the answer is almost always "not yet."
Will my MVP code need to be rewritten later?
Some of it, yes. That's fine. MVP code is meant to be disposable — it exists to validate an idea, not to run in production for 5 years. If your MVP succeeds, budget 2-3 months for a proper rewrite of the core. If it doesn't succeed, you saved months by not over-engineering it.