A landing page takes about 2 to 4 weeks, a multi-page site 4 to 8, and a SaaS MVP roughly 6 to 10 weeks — when scope is clear and feedback is fast. Most timelines slip for the same reasons: unready content, slow decisions, and scope added mid-build. The realistic number isn't only the build; it's the build plus your response time. Plan for both and a launch date stops being fiction.
How long do common projects take?
Rough, honest ranges: a focused landing page, 2 to 4 weeks; a multi-page business site, 4 to 8 weeks; a SaaS MVP, about 6 to 10 weeks. These assume a clear scope and prompt feedback. They cover design, build, and a real QA pass — not a rushed "it compiles, ship it." Page count and feature count move the number, but so does how fast decisions get made on your side. Both are genuinely part of the timeline. One thing those ranges hide: they're calendar time for a focused build with one person or a tight team, not a queue behind ten other clients. If a quote promises a complex app in a few days, that's a warning, not a deal — real software has a floor that rushing can't beat without cutting the parts you can't see.
What are the phases inside a timeline?
Most builds run the same arc: scope and content prep, design, build, then QA and launch. Scope and content prep is the one people skip and the one that decides everything — design needs real copy, not placeholder. Build is the visible part but rarely the real bottleneck. QA and launch is where the pre-launch checks happen. When a project feels slow, it's usually stuck in prep or feedback, not in the code itself. A rough split for a typical build: prep and design take the first third, the build takes the middle, and QA and launch take the final stretch — but the prep third is the one that decides whether the rest runs on time. Content and decisions gathered before design starts are what keep build and QA from absorbing delay later.
What stretches a timeline the most?
Three things, every time: content that isn't ready, feedback that takes a week per round, and scope added after the plan is set. None are code problems. A single slow review cycle can add weeks across a project, and one mid-build feature can push the date out further than it looks. I flag these at the start, because the honest timeline depends as much on your response speed as on my build speed. Both sides set the date. The quiet one is "just one more thing" after the plan is set: each addition looks small, but it reopens design, build, and QA at once, so a mid-build feature costs more than the same feature scoped from the start. That's why I park new ideas for a fast follow rather than letting them stretch the launch — covered in what "done" means for a first release.
Why are software estimates so often wrong?
Because most estimates price the building and forget everything around it. The code is the visible part, but a real timeline also includes content prep, design decisions, review cycles, QA, edge cases, and launch — and those are exactly the parts that get waved away in an optimistic quote. The other reason is the unknowns: any build hits a few surprises, and an estimate with zero slack assumes a perfect run that rarely happens. An honest timeline names the phases, builds in your response time, and leaves room for the unexpected. A number with none of that isn't a plan; it's a hope, and it's why so many projects "suddenly" run late.
How do you set a deadline you can actually hit?
Work backward from a scoped v1, not forward from a wish. Start by locking exactly what ships in the first release, add realistic ranges for each phase, build in your review time, then leave a little slack for the unknowns every project hits. A date set that way is one you can defend; a date picked because it sounds good — "live in two weeks" with no scope behind it — is just pressure that gets paid back in cut corners or a slip. If a fixed deadline is non-movable, then scope becomes the lever: ship a smaller, sharper v1 by the date and fast-follow the rest. Pick the date and the scope together, because you can't fix both independently.
How do I keep a project on track?
I scope the phases, prep content up front, set the feedback cadence, and lock the v1 feature list before design — then park new ideas for a fast follow instead of letting them move the launch. It's the same discipline across my services, whether it's a site or an MVP. A realistic timeline isn't a guess; it's a plan with your decisions built into it. Come prepared and the date holds.
Related strategy guides
See how long it takes to build a website, how long it takes to build an MVP, and what "done" means for a first release.
Need a real timeline for your project? Tell me what you're building — I'll map it phase by phase to a launch date.
