An MVP is not the smallest version of your product. It is the smallest version that proves your riskiest assumption. The difference is huge. "Smallest version of the product" leads to a feature-list that gets cut by 30%. "Smallest version that proves the riskiest assumption" leads to a focused build that ships in 8 weeks and tells you whether to keep going.
Step 1: Name the riskiest assumption
Every business idea has a stack of assumptions. The riskiest one is the one that, if wrong, kills the whole idea. For a B2B SaaS, that is usually "customers will pay for this." For a consumer app, it is usually "users will come back next week." For a marketplace, it is "we can attract supply faster than demand burns out."
Name the assumption first. Everything else flows from it. If you cannot name the riskiest assumption, you cannot define what "validated" looks like — and you cannot know when the MVP has done its job.
Step 2: Define the minimum to test it
For a B2B SaaS testing "will they pay": the minimum is one user, one workflow, real billing, and the actual problem solved. You do not need a settings page. You do not need a team feature. You do not need a marketing site. You need a working product, a payment form, and one customer paying real money.
For a consumer app testing "will they come back": the minimum is one screen, one core action, push notifications, and analytics. You do not need profiles. You do not need social features.
This is where 90% of founders go wrong. They define "minimum" as "everything we promised in the pitch deck." Real minimum is brutal.
Step 3: Plan the 6–10 week sprint
A real MVP fits in 6–10 weeks. Less is usually corner-cutting; more is usually scope creep. Here is the breakdown we use at Vybix, derived from every MVP we have shipped:
- Week 1: Discovery. Architecture document. Explicit list of what we are NOT building.
- Week 2: Foundations. Repo, CI/CD, staging + production environments, design system, database schema.
- Weeks 3–6: Sprint-based build. Two-week sprints. Demo on Friday of every sprint.
- Weeks 7–8: Integrations. Stripe billing, transactional email, error monitoring, basic analytics.
- Week 9: Launch hardening. Load test, OWASP review, accessibility.
- Week 10: Handover and launch.
Step 4: Build production code from day one
The biggest myth about MVPs is that the code should be throwaway. It should not. The code you ship in week 10 is the code you take to your first 1,000 customers. Throwaway MVPs lock you into a 6-month rewrite the moment you find product-market fit — exactly when you can least afford to stop shipping features.
Our MVPs are real production systems. Multi-tenant where it matters. Stripe billing wired in. Error monitoring from day one. Documented architecture. The cost is maybe 15% more than a throwaway prototype. The savings on the rewrite that does not happen are 100×.
Step 5: Ship the riskiest features first
Inside the 6-week build window, sequence matters. Most teams ship the easy features first — the login, the dashboard skeleton, the settings page — and leave the risky part (the actual differentiator) for the end. By the time they get to the risky part, the budget is gone and the demo gets pushed.
Flip it. In week 2, while we are still building foundations, we are also building the riskiest workflow. By week 4, the risky feature is demoable. If it fails, we still have 6 weeks to pivot. If we save it for week 8 and it fails, we have no time and no budget.
Risk-first sequencing is the single biggest reason our MVPs ship on time. Easy features are easy precisely because they can wait.
Step 6: Validate hard
The MVP is not the goal. The validation is. After launch, you have 4 weeks to answer one question: did the riskiest assumption hold? If yes, raise capital and scale. If no, pivot — but cheaply, because you only spent 10 weeks finding out.
Most founders skip this step. They launch the MVP, declare victory, and start adding features. Six months later they realise the assumption was never validated — they just got busy. The MVP becomes the product by default, and the riskiest assumption is still untested.
The honest part: what most MVPs get wrong
Three patterns we see over and over:
- Too many features. "Just one more thing" kills more MVPs than under-scoping.
- No payment flow. A free product cannot test the "will they pay" assumption. Wire in Stripe from week 3 even if you give the first 10 customers a 100% off code.
- No real users in the build loop. Build with 3 real customers watching the weekly demos. They will save you from features no one needs.
Build the MVP that tests the riskiest assumption. Build it in production code. Ship the risky features first. Validate hard. The framework is simple — execution is where most teams fail.