What an MVP Actually Is (and Isn't)
An MVP (Minimum Viable Product) is not a half-built version of your full product. It's the smallest set of features that lets real users do the core job you're solving for them — and lets you learn whether you've solved it correctly. An MVP has one primary use case, handles it well, and ships. Everything else comes after you have evidence that users want it.
The most common MVP failure: founders build an "MFP" (Minimum Fancy Product) with every feature from their dreams, 6 months and $150,000 in development, and launch to discover nobody wanted it.
The 90-Day MVP Framework
Weeks 1–2: Problem and Scope Clarity
Before writing a line of code, answer four questions with evidence (user interviews, market data, existing behaviour):
- What is the specific problem you're solving? (One sentence.)
- Who exactly is the customer? (Not "SMBs" — "B2B SaaS companies with 10–100 employees struggling with invoice reconciliation")
- What is the one core action users need to take in your product?
- What is the single metric that proves your MVP is working?
Output: A one-page MVP scope document. If you can't describe your MVP in one page, it's not an MVP.
Weeks 2–4: Design and Architecture
Wireframes for all MVP screens (5–15 screens for a typical SaaS MVP). One round of user testing on wireframes — validate flows before building them. Architecture decisions: stack, infrastructure, third-party services. Tech debt decisions: what corners to cut consciously (and document) vs what quality standards are non-negotiable.
90-day MVPs require conscious tech debt. Document explicitly: "We're using synchronous processing here; we'll refactor to queues when we hit 1,000 concurrent users." This is responsible debt. Unacknowledged debt is how 90-day MVPs become unmaintainable 18 months later.
Weeks 4–12: Build Sprints
Four 2-week sprints. Sprint priorities:
- Sprint 1: Core data model + authentication + primary user workflow (the one thing your MVP must do)
- Sprint 2: Complete the happy path end-to-end. First internal demo.
- Sprint 3: Secondary flows, error handling, edge cases. First beta user testing.
- Sprint 4: Polish, bug fixing, performance, onboarding flow, launch preparation.
What doesn't belong in a 90-day MVP: admin panels (use direct database access initially), advanced analytics (use Mixpanel/Amplitude, not custom charts), notification preferences, billing (launch with manual invoicing), mobile app (launch web-first).
Week 12+: Soft Launch and Learning
Launch to 10–30 design partners — users who agreed to try it in exchange for influence on the roadmap. Goal: qualitative learning, not traffic. Questions to answer: do users complete the core workflow? Where do they get stuck? What feature do they ask for immediately after the core workflow?
What Does a 90-Day MVP Cost?
With an India-based development team:
- Simple SaaS MVP (web app, one core workflow, basic auth): $15,000–$25,000
- Marketplace or two-sided platform MVP: $25,000–$45,000
- Mobile app MVP (React Native): $20,000–$35,000
- AI-powered SaaS MVP: $25,000–$50,000
Teams that try to build MVPs for $5,000–$8,000 typically get: freelance developers with no PM, no QA, no architecture review, inconsistent availability, and 3–4 months of "almost done" before receiving unusable code. The $15,000–$25,000 range gets you a 3-person team (developer + QA + PM), 2-week sprints, daily standups, and code you can build on.
The Fastest Path to 90 Days
Three decisions that dramatically accelerate MVP timelines:
- Narrow scope ruthlessly: Every feature debate costs a week. The fastest teams have a PM empowered to say no to any in-sprint scope addition.
- Choose boring technology: React + Node.js + PostgreSQL + AWS is not exciting but it's what moves fastest because the entire team already knows it. Avoid "learning opportunities" in MVP sprints.
- Start with Stripe, Auth0, and a component library: Don't build auth, payments, or UI components from scratch in an MVP. Use proven libraries and focus engineering time on your unique value.