How Long Does MVP Design Take? A Realistic B2B Timeline
Three to five weeks for one workflow, eight to twelve for a multi-role B2B product. Where the weeks go, the four things that stretch them, and what you can safely cut.
Mike Lopez
Designs and builds websites and B2B software
On this page
Most MVP design takes somewhere between three and twelve weeks, and the spread is not vague estimating. A first version with one workflow for one kind of user is three to five weeks of design. A first version with two or three roles, which describes most B2B products, is eight to twelve. Where yours lands depends less on the number of screens than on four things that quietly stretch the calendar, and all four can be managed if you know about them before the first call.
This is how I plan MVP design timelines for B2B and SaaS teams: where the weeks actually go, what stretches them, and what you can cut without cutting the part that decides whether anyone uses the product.
The short answer
| First version | Design time | What it usually covers |
|---|---|---|
| One workflow, one role | 3 to 5 weeks | A single job done end to end, such as placing a reorder or approving a request |
| Two or three roles on one platform | 8 to 12 weeks | A customer side and an admin side, with permissions and shared data |
| An audit before you commit | 1 to 2 weeks | Whether the problem is design, engineering, or a process nobody has written down |
| Design plus front-end build | Add 3 to 6 weeks | The designer builds the interface rather than handing it over |
These are design weeks, not calendar weeks from signing. Engineering usually starts before design finishes, and it should, which I come back to below. For how the same bands translate into budget, see the B2B SaaS design cost breakdown.
Where the weeks go
An MVP timeline is not one long block of screen design. It is four stages, and the last three depend on the first. For a single workflow that is roughly a week of discovery, two of structure and two of interface. A multi-role product stretches every stage, the interface most of all.
Discovery: one to two weeks
Interviews with the people who will use the product, a walkthrough of how they do the job today, and a look at whatever they use instead, which in B2B is usually a spreadsheet and a chat thread. On Roadcase, a tour budgeting MVP, that meant tour manager interviews, settlement walkthroughs and a pile of historical tour budgets before anything was drawn. It is the cheapest stage in the project and the one teams most want to skip.
Structure: one to three weeks
The data model as users see it, the navigation, and the states each object moves through. For an ordering product, that means what an order is, who can change it, and what happens when it is half finished. Most of the decisions that make an MVP usable get made here, in flows and diagrams, where changing your mind costs an afternoon rather than a sprint.
Interface: two to six weeks
High fidelity screens for every state, including the empty one, the error, and the case with far more data than anyone demoed. A lean component set comes out of this stage rather than preceding it. For a one-workflow MVP this is two weeks. For a multi-role product it is the bulk of the calendar.
Handoff and build support: ongoing
Annotated specs, and a designer who stays reachable while engineering builds. On Roadcase the specs went to engineering as Figma Dev Mode annotations rather than a separate document, because a document is out of date the first time someone asks a question, and the questions always come.
Four things that stretch an MVP timeline
1. The minimum keeps growing
Every stakeholder meeting adds one feature that is needed for launch. Each one is small. Together they turn a five-week MVP into a twelve-week product. Write down the one job the first version must do, and treat every addition as a trade against the launch date rather than a free extra.
2. No access to real users
B2B users are busy, often senior, and frequently work for your customer rather than for you. If it takes three weeks to schedule five interviews, discovery takes three weeks. Line the people up before design starts, even if it is only four conversations.
3. A role discovered late
The most expensive surprise in B2B design is the approver nobody mentioned. A second role arriving halfway through the interface stage means revisiting permissions, navigation and many of the screens already designed. Ask early who else touches an order, a request or a record, and who is allowed to change it.
4. Feedback that arrives in several voices
When the founder, the head of sales and the lead engineer each review separately, one review round becomes three, and the comments contradict each other. One consolidated round of feedback a week keeps a timeline on schedule better than anything a designer can do alone.
What you can cut, and what you cannot
Cutting scope is the right way to shorten an MVP. The question is which scope.
- Cut: secondary roles you can serve by hand for now, settings screens, bulk actions nobody has asked for, visual polish beyond clear and consistent, and a full design system. A token set and the components the first version actually uses are enough.
- Keep: empty and error states, the path a first-time user takes, permissions for the roles you do ship, and the one screen people will spend all day on. These decide whether the first version gets used or quietly abandoned.
The difference matters because B2B users rarely give a product a second chance. Nobody complains that the settings screen is missing. They complain when the screen they live in cannot handle the week’s real orders.
How to shorten it without cutting corners
Start engineering on structure, not screens. Once the data model and the states are agreed, engineers can build the backend while the interface is designed. That overlap is where most real schedule gets won.
Design one workflow at a time. Ship the core job, watch people use it, then design the next. Designing the entire product before building any of it means the last third of the design rests on assumptions the first third already disproved. It is the same reasoning behind phasing the cutover in a legacy B2B portal redesign.
Decide who decides. One person with authority to approve the design, and a fixed weekly slot to do it. It sounds administrative. It removes more calendar time than any tool.
Frequently asked questions
Can an MVP be designed in two weeks?
A single, well-understood workflow with one role and research already done, yes. Anything with more than one kind of user, or where nobody has talked to those users yet, no. Two-week MVP design usually means discovery and structure happened somewhere else, or did not happen at all.
How long does MVP development take after design?
That depends on integrations and team size far more than on design, so I will not pretend there is one number. What design controls is the overlap. Once the structure is agreed, backend work can start while the interface is still being designed, and the combined calendar ends up shorter than the two phases added together.
Do I need a design system for an MVP?
You need the start of one: colour and type tokens, and the components the first version actually uses, built properly in Figma. A documented system is a second-version investment. Skipping even the tokens, though, is how an MVP ends up with nine slightly different greys by month three.
Is a clickable prototype the same as MVP design?
No. A prototype shows the happy path well enough to test an idea or pitch it. MVP design covers what engineering needs to build a real product: every state, permissions, validation and the handoff. A prototype is often a week of work inside the discovery or structure stage, not a replacement for either.
Does working with a designer in another timezone slow an MVP down?
Not if the overlap is planned. A few shared hours a day and decisions kept in writing are enough, and a designer working while your team sleeps can turn feedback around overnight. I cover the practical side in working with a B2B UI/UX designer in the Philippines.
Planning an MVP?
If you have a first version in mind, send me the rough brief and I will tell you which band it falls in and what is most likely to stretch it. You can see how a recent MVP came together, from interviews to Dev Mode handoff, in the Roadcase case study.
