Most founders think building an MVP means building a small version of their full product.

It doesn't. And that misunderstanding is what causes most early-stage products to take 6 months, cost ₹40 lakhs, and still not find a single paying user.

At Pexovar, we've helped founders go from idea to live product in 6 weeks. Here's the exact framework we use — and why speed without shortcuts is completely achievable.

Why most MVPs fail before they launch

The number one reason startups burn through money on MVPs that go nowhere isn't bad engineering. It's building the wrong thing.

We've spoken to founders who spent 8 months and ₹25 lakhs building a product with 14 features — only to discover that users wanted exactly one of them. The other 13 were based on assumptions nobody validated.

A properly scoped MVP has one job: validate the riskiest assumption in your business as cheaply and quickly as possible.

That's it.

Not "build a polished product." Not "match the competitor's feature list." Validate the one thing that, if wrong, means your entire business model doesn't work.

The 6-week framework

Here's how we structure a 6-week MVP build at Pexovar.

Week 1: Scope ruthlessly

This is the most important week. We do not write a single line of code.

We run a product discovery session with the founder covering:

  • What is the single core action a user needs to complete for this product to have value?
  • What does success look like after 90 days of being live?
  • What are we deliberately NOT building in this version?
  • Who are the first 10 users and what do they actually need?

The output is a one-page scope document. Not a 40-page PRD. One page. If you can't describe your MVP in one page, the scope is too large.

Common scope culprits to cut from V1: admin dashboards, social features, notifications, multiple user roles, onboarding tours, settings pages, and anything that doesn't directly enable the core action.

Week 2: Design the critical path only

We design only the screens that sit on the critical path — the minimum sequence of screens a user needs to complete the core action.

For most consumer apps, this is 5–8 screens. For B2B tools, sometimes 3–5.

We use Figma for high-fidelity mockups of these screens only. We share them with 5 potential users before writing any code. If those users can't figure out the core flow without explanation, we redesign before building.

Weeks 3–5: Build in weekly releases

We ship working code every Friday. Not a demo, not a prototype — working code on a real device.

This does two things. First, it forces prioritisation. You cannot ship everything in one week, so you ship only what matters most. Second, it gives the founder something real to show investors, advisors, and early users every single week.

Our tech stack for most MVPs:

  • Mobile: Flutter (iOS + Android from one codebase)
  • Web/backend: Next.js + Node.js + PostgreSQL
  • Auth: Supabase or Firebase (never build auth from scratch in an MVP)
  • Payments: Razorpay (India) or Stripe (global)
  • Hosting: Railway or Vercel (not AWS — overkill for week 3)

Week 6: Launch to 10 real users

Not a soft launch. Not a beta waitlist. Ten real users, using the product, giving you feedback.

We help founders identify these 10 users in week 1 so they're ready by week 6. They can be friends, colleagues, LinkedIn connections, or people from a relevant WhatsApp group. They just need to be real people in your target market.

The goal of week 6 is not to get 1,000 users. It's to have 10 conversations that tell you whether you built the right thing.

What an MVP should NOT have

This is as important as what it should have.

  • No: Custom admin panel (use Supabase Studio or Retool)
  • No: Push notifications (add in V2 when you know what to notify about)
  • No: Multiple pricing tiers (pick one and test it)
  • No: Referral system (premature)
  • No: Analytics dashboards for users (premature)
  • No: "Social" features — followers, likes, comments (unless that IS the product)
  • No: Native ads or monetisation in V1 (learn first, monetise second)

Every one of these features is a week of engineering time. In a 6-week MVP, every week is 16% of your entire timeline.

The budget question

A 6-week MVP with a professional team in India typically costs between ₹3–8 lakhs depending on complexity.

If someone quotes you ₹50,000 for a "complete app," you're getting a template with your logo on it. If someone quotes you ₹40 lakhs for an "MVP," they're building a full product and calling it an MVP.

The sweet spot for a genuinely validated, well-engineered MVP is in the middle — and the investment pays back quickly when you find product-market fit faster.

The question to ask before you start

Before any code is written, ask yourself: "What would I need to see after 6 weeks to know this is worth pursuing further?"

Write down the answer. Share it with your dev team. Build toward that answer, and nothing else.

That question alone will save you months and lakhs.