How Long Does It Take to Design a SaaS Product? Real Timelines by Scope
Concrete week ranges by project type, where the time actually goes phase by phase, and an honest account of what makes projects run late.
TL;DR: A marketing website takes 4 - 8 weeks. An MVP product design takes 8 - 14 weeks. A full product redesign takes 12 - 20 weeks. A design system foundation takes 6 - 10 weeks. These ranges assume a responsive client, and that assumption is where most projects actually fail. The majority of delay in design projects is client-side: slow feedback, unclear decision-makers, and scope added mid-flight. The single highest-leverage thing you can do for your timeline is name one decision-maker and commit to a 48-hour feedback turnaround.
Why Design Timelines Slip Before Work Starts
Ask five agencies how long a product redesign takes and you will get five answers, most of them useless. "It depends on scope" is technically true and practically worthless when you are trying to plan a launch, brief a board, or work out whether your runway covers the work.
The vagueness is partly self-protective. An agency that commits to twelve weeks and delivers in sixteen has a problem, so many quote wide ranges or refuse to quote at all until discovery is complete. But it is also because the honest answer involves a variable most timeline conversations skip: how fast you will move.
Design is not a process an agency performs on you. It is a sequence of decisions, and roughly half of them are yours. Every estimate you receive silently assumes a feedback cadence, a single decision-maker, and stable scope. When projects run late, it is far more often because those assumptions broke than because the design work was harder than expected.
This post gives concrete ranges by project type, breaks down where the weeks actually go, and is honest about what causes delay. It pairs with our breakdown of what UI/UX design costs in 2026 - together they cover the two questions every founder asks before signing anything.
Real Timelines by Project Type
These are realistic ranges for a competent boutique agency working with a responsive client. Larger agencies typically run longer because of internal coordination; solo freelancers vary enormously.
| Project type | Typical timeline | What drives the range | What you must provide |
|---|---|---|---|
| Landing page | 1 - 3 weeks | Whether messaging exists or has to be developed | Final copy, or agreement that we write it |
| Marketing website (8 - 14 pages) | 4 - 8 weeks | Page count, copy readiness, whether brand exists | Copy, brand assets, one decision-maker |
| Brand identity | 4 - 8 weeks | Number of stakeholders and rounds of direction | Positioning clarity, a small decision group |
| MVP product design | 8 - 14 weeks | Number of core flows, domain complexity, research depth | Access to users, engineering input, prioritised scope |
| Design system foundation | 6 - 10 weeks | Existing UI inventory size, engineering coordination | Engineering partner, component audit access |
| Full product redesign | 12 - 20 weeks | Surface area, legacy constraints, migration strategy | Analytics access, user access, engineering capacity |
| Mobile app design | 10 - 16 weeks | One platform or two, native pattern depth | Platform decision, engineering constraints |
| Pitch deck | 2 - 4 weeks | Whether the narrative is settled | Final narrative and numbers |
| UX audit | 2 - 3 weeks | Product surface area | Analytics and product access |
Two notes on reading this table. First, these are design timelines, not design-plus-build. Front-end development typically runs alongside and beyond design; a marketing site designed in six weeks might take another three to four to build. Second, the low end of each range assumes near-ideal conditions. Plan against the middle.
Where the Weeks Actually Go
Founders often assume most of a design project is spent making screens look good. In a well-run project it is closer to a third. Here is how a twelve-week MVP design engagement typically distributes.
| Phase | Share | What happens |
|---|---|---|
| Discovery & alignment | ~10% (1 - 1.5 wks) | Business goals, constraints, success metrics, stakeholder map, competitive context |
| Research | ~15% (1.5 - 2 wks) | User interviews, analytics review, existing-product audit, synthesis |
| IA & flows | ~15% (1.5 - 2 wks) | Information architecture, core user journeys, state mapping, edge cases |
| Wireframes | ~15% (1.5 - 2 wks) | Low-fidelity structure, layout logic, content hierarchy, early review |
| UI design | ~25% (3 wks) | Visual system, high-fidelity screens, component library, all states |
| Prototyping & testing | ~10% (1 - 1.5 wks) | Interactive prototype, usability testing, iteration on findings |
| Handoff & QA | ~10% (1 - 1.5 wks) | Specs, tokens, documentation, engineering walkthrough, build review |
The phase founders most want to cut is research, because it produces no visible screens. It is also the phase whose removal most reliably causes rework later, since every downstream decision rests on assumptions that were never checked. Our guide to UX research methods covers how to get useful signal in days rather than weeks when the timeline is genuinely tight.
The phase founders most often forget to budget for is handoff and QA. Design that is not properly specified gets reinterpreted during build, and the gap between the file and the shipped product is where most design value quietly leaks out.
What Actually Makes Projects Run Late
Here is the uncomfortable part. In our experience and across the industry, most schedule slippage originates on the client side. This is not a complaint - it is useful, because client-side causes are the ones you can fix.
Slow feedback cycles
The most common cause by a wide margin. A project with six review rounds and a five-day average feedback turnaround loses four weeks to waiting. The same project at 48 hours loses one and a half.
Fix: commit to a feedback SLA in writing before the project starts. Forty-eight hours on standard reviews. Put the review sessions in calendars at kickoff for the whole engagement rather than scheduling each one when it arrives.
No single decision-maker
When feedback arrives from four people with conflicting opinions and nobody empowered to adjudicate, the design team either builds to the loudest voice or stalls waiting for resolution. Both cost weeks.
Fix: name one person who owns the final call. Others advise; one decides. This single change does more for timelines than any process improvement.
Scope added mid-project
"While you're in there, can we also..." is how a ten-week project becomes fifteen. Each addition seems small in isolation, and each carries design, review, and QA cost.
Fix: keep a visible parking lot. New ideas go on the list rather than into the sprint, and you review the list at phase boundaries. This preserves the ideas without derailing the schedule, and it makes the trade-off explicit rather than invisible.
Waiting on copy, content, or data
Design blocked on real content is extremely common. Placeholder text hides layout problems that surface late, and "we'll write the copy later" reliably becomes a two-week hold at the worst moment.
Fix: treat copy as a dependency with its own deadline, ahead of the design phase that needs it. Either assign an owner with a date or ask the agency to write it.
Too many people in reviews
Reviews with nine attendees generate contradictory feedback and consensus-driven mediocrity. They also take longer to schedule, which adds calendar delay on top of decision delay.
Fix: cap review attendance at four. Circulate work async beforehand so the session is for resolving disagreement, not first impressions.
Engineering brought in late
Design that has never been sanity-checked against technical constraints gets redesigned after handoff. This is a particular risk on data-heavy or AI-driven products where what is feasible is not obvious from the outside.
Fix: include an engineer in flow and wireframe reviews, not just handoff. One hour early saves days later.
Late-stage direction changes
A stakeholder who was absent for eight weeks appears at the UI review and questions the fundamental direction. Everything after the questioned decision has to be redone.
Fix: identify every person capable of vetoing the work at kickoff and get them into the discovery and wireframe reviews, where changing direction is cheap.
How to Compress a Timeline, and What It Costs
Sometimes the deadline is genuinely immovable - a fundraise, a conference, a contractual commitment. Compression is possible, but the honest framing is that you are choosing what to give up, not getting the same work faster.
Safe compressions. Reduce scope rather than phases - design four core flows properly instead of nine flows superficially. Use an established design system or a well-chosen template as a starting point instead of building visual language from scratch. Run research and early design concurrently rather than sequentially. Cut review rounds by tightening the decision-making group. Accept a narrower set of states and edge cases in v1, with a documented list of what was deferred.
Expensive compressions. Cutting research entirely means designing on assumption, and you will pay for it in post-launch rework - usually more than the time you saved. Skipping usability testing means shipping problems you would have caught in three sessions. Compressing handoff and QA means engineering interprets ambiguity on your behalf. Adding designers to a late project rarely helps within a single workstream, since coordination cost eats the added capacity.
The rule of thumb: you can safely take twenty to thirty percent off a timeline by narrowing scope and tightening decisions. Beyond that you are trading quality, and you should decide deliberately which quality you are trading rather than discovering it after launch.
Consider how work like Highflyers takes shape - the goal was making executive search feel like a coherent system. That kind of coherence comes from the flow and architecture phases, not from the UI phase. Compressing the early thinking to protect the visual polish inverts the value, and it is the most common compression mistake we see.
Matching Timelines to Runway and Stage
The right timeline is not just about the work, it is about what your runway can absorb.
Pre-seed and bootstrapped. Optimise for speed of learning. A 2 - 3 week landing page or a 4 week focused MVP slice beats a 14 week comprehensive design. You are buying evidence, not a finished product.
Seed with 14+ months of runway. You can afford a proper 8 - 14 week MVP design cycle including real research, and you should. This is the stage where foundations are cheapest to get right - a design system built now costs a fraction of retrofitting one at Series B. See our MVP design guide for how to scope that work.
Seed with under 9 months of runway. Compress deliberately. Narrow to the two flows that prove the thesis, use an existing system, and defer the rest with a written list. Do not attempt a full redesign on short runway.
Series A. A 12 - 20 week redesign is viable, and often necessary because the product has accumulated inconsistency. Run it in phases with shippable increments rather than a big-bang relaunch, so value lands throughout rather than at the end. Our website redesign checklist covers phasing in more detail.
A general planning rule: your design timeline plus your build timeline should fit comfortably inside half your remaining runway. If a project consumes most of your cash before it ships, you have no room to iterate on what you learn - and the iteration is where most of the value is.
Conclusion
Plan for 4 - 8 weeks for a marketing site, 8 - 14 for MVP product design, 12 - 20 for a full redesign, 6 - 10 for a design system. Budget against the middle of the range, not the optimistic end.
Then do the thing that actually protects the schedule: name one decision-maker, commit to 48-hour feedback, get engineering into reviews early, and keep new ideas in a parking lot until a phase boundary. An agency controls maybe sixty percent of your timeline. You control the rest, and in most late projects the client-side forty percent is where the weeks went.
If you have a date you need to hit and want an honest read on whether it is achievable, tell us what you are planning. If the timeline does not work, we will tell you what to cut rather than quietly running late.
Straight Answers
