Somebody asked me last week why our first roadmap for a payments tool had eleven milestones on it. Eleven. For a product that at that point did one thing: it let a user connect a bank account and see a balance. The roadmap looked impressive in a pitch deck and was worthless as a planning instrument. We missed every single date on it.
That failure taught me more about how to build a minimum viable product roadmap than any framework ever did. Not because the framework was wrong, but because we'd confused a roadmap with a wish list. A real MVP roadmap is a short, dated, brutally honest document that tells you what you're testing, in which order, and what result would make you stop. Most teams write the opposite: a long document that tells everyone what they'd like to be true.
Key takeaways
- A viable MVP roadmap fits on one page: three to five milestones, each with an exit criterion that can be measured, not argued about.
- Each milestone should answer exactly one question about your user. If a milestone answers two, split it.
- Budget for four to twelve weeks of build time for most software MVPs, and treat anything beyond that as a scope problem rather than a scheduling problem.
- Define the metric that would kill the project before you write the first line of code. Otherwise you'll rationalize the results afterwards.
- The roadmap after product-market fit looks nothing like the roadmap before it. Plan for the handover.
Why most MVP roadmaps fail before the first sprint
The pattern repeats. A founder has an idea, opens a spreadsheet, and starts listing features. Authentication, payments, notifications, an admin panel, a settings screen. It feels productive. It is actually avoidance: writing feature names is easier than deciding which single assumption your business depends on.
Here's the thing about assumptions. An MVP exists to test them, and most products rest on a handful of them. Will people care enough to sign up? Will they come back a second time? Will anyone pay, and how much? Each of those is a separate question, and each deserves its own milestone with its own measurement.
Stop confusing a roadmap with a feature list
A feature list says what you'll build. A roadmap says what you'll learn, in what order, and by when. The distinction matters because features have no natural stopping point. You can always add one more. Learning does have a stopping point: once you know whether people will pay, the question is closed and you move on.
I made this mistake on a scheduling tool in 2023. The roadmap listed screens. It should have listed questions. We shipped all the screens in nine weeks and still had no idea whether small studios would pay a monthly fee, because we'd never designed a milestone that measured payment intent. Nine weeks, and the central question stayed unanswered.
An MVP roadmap is a decision instrument, not a delivery plan
There's a second confusion hiding underneath. Teams treat the roadmap as a commitment to stakeholders, which makes every date sacred and every scope cut feel like a breach of contract. That's backwards for an MVP. The dates should be firm, the scope should be flexible, and the roadmap should make clear which parts you're willing to throw away.
Look, this is uncomfortable for anyone who has to report upward. I get it. The way I've handled it is to present the roadmap as a sequence of go/no-go gates: if milestone two shows nobody returning, milestone three doesn't happen and we've saved six weeks. Executives accept that framing far more readily than they accept a vague promise of "iterating."
How to build a minimum viable product roadmap, step by step
What follows is the sequence I actually use now. It takes about a day of work for the document itself, plus whatever time you need to argue about it with your cofounders. That argument is the valuable part.
Step 1: write down the one assumption that would sink you
Not the riskiest-sounding one. The one whose failure makes everything else irrelevant. For a marketplace, it's usually whether supply shows up. For a B2B tool, it's often whether the buyer can get budget approved. For a consumer app, it's retention past week two.
Write it as a falsifiable sentence: "At least 20% of trial users will return in the second week without us emailing them." If you can't phrase it as a number, it isn't an assumption, it's a hope.
Step 2: turn assumptions into milestones with exit criteria
Each milestone gets three fields: what you build, by when, and the number that lets you proceed. Nothing else. This is where most teams over-write, adding dependencies and owners and risk registers. Resist. A one-page roadmap with real exit criteria beats a twelve-tab project plan every time.
| Milestone | What gets built | Duration | Exit criterion |
|---|---|---|---|
| 1. Signal | Landing page, waitlist, pricing shown | 5 days | 4% of visitors join the waitlist |
| 2. Core loop | The single action the product exists for | 3–4 weeks | Half of testers complete the action unaided |
| 3. Return | Whatever makes a second visit plausible | 2–3 weeks | 20% of testers come back within 7 days |
| 4. Money | Payment flow, even if manual behind the scenes | 2 weeks | Three people pay without a discount |
Note the shape. The expensive engineering sits in the middle; the first and last milestones are cheap and answer the two most dangerous questions. If you can, run milestone one before you commit to the rest.
Step 3: sequence by cost of being wrong, not by technical dependency
Engineers naturally order work by what unblocks what. For an MVP, order by what's cheapest to learn first. This often means building the ugly version of the thing you're least sure about, and skipping the polished version entirely until someone asks for it twice.
A concrete example: on a document tool, we spent eleven days on file-format support nobody had requested, and forty minutes on the empty-state screen that every single new user saw first. Guess which one moved activation. Activation went from roughly a third of signups to just over half once we rewrote that screen. Forty minutes.
Step 4: set the dates, then defend the scope instead
Pick a launch date and treat it as fixed. When something slips, cut a feature, not the date. This inverts normal project management and it feels wrong for the first two weeks. It works because the date is the only thing that forces the trade-off to happen consciously rather than silently.
The corollary: don't put anything on the roadmap you're not prepared to cut. If a milestone can't be dropped without the product becoming meaningless, that milestone is your MVP and everything else is post-launch.
How long should an MVP take to build?
For most software MVPs, expect four to twelve weeks of build time from a small team, with six to eight weeks being the common case. The variance comes almost entirely from how much you insist on building versus faking. A landing page test takes days. A working core loop with real data takes weeks. Anything past three months usually means scope crept in through the back door.
Three factors move that number more than anything else:
- Whether you need to touch money. Payment integration, invoicing, and tax handling add weeks, not days.
- Whether your data is dirty. If you're importing from spreadsheets or legacy exports, budget real time for cleaning it—more than you think.
- Whether a human can stand in for the software. Manual onboarding, a spreadsheet behind the scenes, a daily email written by hand. Every manual step you allow yourself removes a week of engineering.
What actually stretches the timeline
In my experience the delays are rarely technical. They come from three sources, and all three are decisions rather than surprises: redesigning the interface twice because nobody signed off on the first version, adding a feature because one early user asked nicely, and waiting on a third-party account approval you could have requested on day one.
My honest rule: if the MVP can't ship in eight weeks, the idea is too big for one MVP and needs splitting. Ship the smallest slice that tests something, then decide.
How much does it cost to build an MVP?
The honest answer is that it ranges from a few thousand euros to well over a hundred thousand, and the spread has almost nothing to do with which technology you pick. What drives cost is headcount and how much you delegate.
| Approach | Typical range | What it buys you |
|---|---|---|
| Founder builds it | Tooling and hosting only, low hundreds per month | Slowest calendar time, fastest learning, total control |
| One freelancer, part-time | Mid four figures to low five figures | Good for single-loop products with no integrations |
| Small agency | Five figures and up | Faster delivery, less flexibility, more coordination overhead |
| In-house pair plus designer | Salaries, effectively a quarter of runway | Fastest iteration once the team knows the domain |
Two cost traps I've walked into personally. First, treating infrastructure as free until the bill arrives—cloud hosting and third-party APIs can quietly cost more per month than the whole build if you're careless with file storage or background jobs. Second, hiring an agency for an MVP whose value depends on daily iteration. An external team delivers a finished thing; an MVP needs something that changes every week.
How can I build an MVP for my idea?
Start with the smallest artifact that produces real evidence, and make sure the evidence comes from strangers rather than friends. In order of increasing cost: a written explanation of the product with a signup form, a clickable mockup you walk people through, a manual service where you do the work by hand, then software.
Can you give me an example of an MVP?
The classic example everyone cites is a shoe retailer that started by photographing shoes in local shops and buying them only after an order came in—no warehouse, no inventory, no risk. The product was real; the infrastructure was fake. That's the whole pattern in one sentence.
I've got a smaller one from my own work. A team wanted to build a scheduling platform for driving instructors. Instead of the platform, they built a single page with a calendar and a phone number, and one person manually booked every lesson for six weeks. Cost: near zero. What they learned: instructors didn't want software, they wanted someone to handle the no-shows and cancellations, which was a completely different product. They found that out in six weeks instead of six months, and pivoted the roadmap accordingly.
What goes on the roadmap after the MVP validates?
This is where the document changes character. Before validation, the roadmap is about closing questions. After validation, it's about widening a working loop: more of what already works, fewer new bets. The metrics shift from testing assumptions to retention, activation, and unit economics.
The mistake I see most often is keeping the same roadmap file and just adding rows. It stops being useful around the third month post-launch. Archive it and write a new one with different exit criteria—that's a signal to the team that the phase has genuinely changed.
The roadmap that fits on one page
Here's what I'd want you to take away from all of this. The document itself is not the point. What matters is that you've been forced to write down, in dated and measurable terms, which assumption you're testing first and what result would make you stop. If your roadmap can't tell you when to quit, it isn't a roadmap—it's a business plan with sprint numbers attached.
And the uncomfortable part: the best MVP roadmap I ever wrote was two milestones long and embarrassed me when I showed it to an investor. It shipped in five weeks, and one of the two milestones killed a feature I'd been certain about for months. I'd rather be embarrassed by a short document than surprised by a long one.
