An MVP, a minimum viable product, has one purpose: to learn whether your idea works with real users, as cheaply and quickly as possible. Yet most MVPs we are asked to rescue are six months late and carry features nobody has used. The problem is almost never the code. It is the scope.
Start with one job, not a feature list
Before talking about screens, write one sentence: "[User] uses [product] to [do one job] so that [outcome]." If you can't fill it in, you are not ready to design. If you need the word "and" twice, you have two products.
For a therapy app, the job might be "people waiting for treatment use the app to complete a short daily exercise so they feel better sooner". Everything in the MVP should serve that sentence. Profiles, social sharing and dark mode can wait.
Cut features with a simple test
List every feature you have imagined, then ask three questions about each one:
- Would a user fail to complete the core job without it?
- Would we be unable to measure whether the idea works without it?
- Is it legally or ethically required, for example data protection or accessibility?
Only features that get a "yes" stay. Everything else goes on a "later" list, which is not a graveyard; it becomes your roadmap once you have evidence. Teams are usually surprised to find that a third of the original list survives.
If you are not slightly embarrassed by how little your MVP does, you probably waited too long to launch it.
Fake what you can. Manual onboarding, a spreadsheet admin panel or a human answering "automated" messages are fine at MVP stage. Automate them once you know people want them.
A 12-week plan that holds
Twelve weeks is long enough to build something real and short enough to keep everyone honest. Here is the shape we use with most clients:
- Weeks 1–2: Discovery. User interviews, the one-job sentence, the cut list and a clickable prototype of the core flow.
- Weeks 3–4: Design. Test the prototype with five to eight target users, fix what confuses them and set up a lean design system.
- Weeks 5–10: Build. Three two-week sprints. Every sprint ends with working software you can tap through, not a status report.
- Weeks 11–12: Harden and launch. QA, analytics, app store submission and a soft launch with a small group of real users.
The important part is that scope is fixed and time is fixed. When something new comes up mid-build, and it will, something of equal size leaves the sprint.
Decide what success looks like before launch
An MVP without a success metric is just a small product. Pick one or two numbers tied to the job: weekly active users completing the core action, retention after 30 days or conversion from trial to paid. Set a target, launch, and review the numbers with the team after four to six weeks.
If the numbers are good, you have earned the right to build the "later" list. If they are not, you have learned something valuable for a fraction of the cost of a full product, and you can change direction quickly.
This is the same process we follow in our MVP development service, where most MVPs launch in 8 to 12 weeks.
