Product
The biggest misconception about the "minimum viable product" is the word minimum. The goal isn't to build as little as possible, it's to build the most focused thing possible: the smallest version that genuinely tests your riskiest assumption. A cramped, half-working pile of features tests nothing. One core journey done well tells you whether you have something real.
Ten weeks is enough time to ship that, if you spend the time on the right things. Here's the plan we use.
Weeks 1–2: Discover and scope
This is the phase teams are most tempted to skip, and skipping it is what produces a wishlist instead of a product. Spend it defining one core user journey, the single path that proves or disproves your core hypothesis.
- Write down your riskiest assumption in one sentence. The MVP exists to test it.
- Map the one journey end to end. Everything not on that path goes to the backlog, not the build.
- Agree on what "success" looks like in numbers before you write any code.
Weeks 3–4: Lay foundations
Decisions you make here are the ones that either prevent or cause an expensive rewrite later. You're not over-engineering, you're choosing a base that can grow.
- Pick a simple, proven architecture sized for an MVP, not for a million users (more on that here).
- Stand up a small design system, even a few well-made components keep the product coherent and speed up every screen after.
- Get CI, environments, and a deploy path working now, so shipping in week 10 isn't a fire drill.
Weeks 5–9: Build in weekly iterations
This is the bulk of the work, and the discipline that makes or breaks the timeline is simple: demo every week. A working build every Friday keeps everyone honest and surfaces problems while there's still time to react.
- Ship a thin slice of the core journey first, then deepen it.
- When the timeline slips, cut scope, not quality. A smaller, polished MVP beats a bigger, broken one.
- Keep a visible "not now" list so cut ideas feel parked, not lost.
If a feature isn't on the one journey you're testing, it's not part of the MVP, it's part of v2.
Week 10: Harden and launch
The last week is for the things that make a product feel trustworthy: testing the core paths, fixing the rough edges, and setting up the analytics that will tell you whether your assumption held. Resist the urge to cram in "just one more feature." Launch clean, and leave a clear, prioritized backlog for v2.
What to cut, and what never to cut
| Safe to cut for v1 | Never cut |
|---|---|
| Secondary features off the core journey | A polished first-run / onboarding experience |
| Admin tooling and edge-case flows | Reliability of the one core path |
| Customization and settings depth | Basic analytics to measure success |
| Visual flourishes that don't aid the journey | A foundation you can build v2 on |
How we run 10-week MVPs
This is exactly the playbook behind our mobile app MVP case study, where a wellness startup went from concept to a 4.9★ app in the stores in ten weeks, and reached 80k users within six months. Focused scope, real foundations, weekly demos, clean launch.
If you've got an idea and a deadline, talk to us. We'll help you scope the version worth building first.