A simple small business website — 3-5 pages, no custom booking or e-commerce — typically takes 2-3 weeks from kickoff to launch when the client is responsive; a more complex site with booking, online ordering, or custom functionality runs 4-8 weeks. The number that matters most to a client isn't the fastest possible timeline — it's an accurate one they can plan around.
Timeline mismatches are one of the most common sources of client frustration in web design, and they're almost always avoidable. Clients rarely complain about a project that takes 5 weeks when they were told 5 weeks. They complain, loudly and often publicly, about a project that takes 5 weeks when they were told 2.
A Realistic Timeline by Project Type
| Project type | Realistic timeline | What drives the range | |---|---|---| | Simple brochure site (3-5 pages, no custom features) | 2-3 weeks | Client response speed, content readiness | | Standard small business site with booking or contact flows | 3-5 weeks | Integration testing, content collection | | E-commerce (product catalog, checkout) | 5-8 weeks | Payment setup, inventory structure, testing | | Multi-location or franchise site | 6-10 weeks | Content volume, stakeholder alignment across locations | | Full rebrand + website | 8-12 weeks | Brand work has to finish before final design locks |
These ranges assume a single freelancer or small team, not a large agency with more parallel capacity. They also assume reasonably prompt client feedback — which is the single biggest variable that actually determines whether a project finishes on time.
What Actually Eats Timeline (It's Rarely the Build Itself)
Most freelancers underestimate how much of a project's real-world duration is outside their own work:
- Content collection. Waiting on the client for photos, copy, logo files, and business details is consistently the single biggest source of delay. A build that would take 8 working days often stretches to 4 calendar weeks because content trickles in slowly.
- Feedback turnaround. A client who takes 5 days to respond to a design review adds 5 days to the timeline, even if your actual work only takes an hour once you have their input.
- Revision rounds without a defined limit. Open-ended "let me know what you think" reviews without a structured number of rounds can turn a 3-week project into a 3-month one.
- Scope additions mid-project. A booking flow added after the timeline was already set is a new scope item, not a delay — but without a clear process to flag it, it just quietly extends the deadline instead.
How to Set a Timeline That Protects Both Sides
- Build content collection into the timeline explicitly, with its own deadline, not an assumption the client will have everything ready on day one. "Content due by [date]" as a stated milestone shifts responsibility for that delay where it belongs.
- Cap revision rounds (2-3 is typical) and state it up front, so both sides know when "still refining" becomes a new scope conversation instead of an open-ended loop.
- Quote a range, not a single date, especially for anything beyond a simple brochure site — "3-4 weeks from when we have your final content" sets a realistic, defensible expectation.
- Build in the QA pass as its own timeline step, not something squeezed into the last day before launch — see the pre-delivery checklist for what that pass actually involves.
- Flag scope changes the moment they happen, in writing, with their timeline and cost impact stated plainly — this is the core discipline covered in how to handle scope creep with web design clients.
Why Timeline Accuracy Is a Trust Signal, Not Just a Logistics Detail
A client who's told an accurate timeline and watches it play out exactly as described walks away with a specific, valuable impression: this person is organized and tells the truth about what to expect. That impression is worth more to your referral pipeline than almost any single design decision, because it's the thing clients repeat to other business owners — "they said 4 weeks and it was ready in 4 weeks." Compare that to a vague or optimistic timeline that slips, which produces the opposite story, regardless of how good the finished site turns out to be.
Rushing vs. Realistic: The Actual Trade-off
There's real pressure to quote fast timelines to win the project against competitors. But a rushed timeline usually shows up later as skipped QA, missed features, or exactly the kind of amateur-looking errors covered in what makes a website look professional vs. amateur. A realistic timeline that includes proper testing and a real polish pass produces a site worth referring; a rushed one produces a site that might just barely pass first inspection and then quietly disappoints once the client's customers start using it.
Where This Fits in the Framework
This follows the pre-delivery checklist, since QA time is one of the timeline components most often squeezed out under deadline pressure. Next: website accessibility basics every designer should know, another delivery-quality dimension worth building into the same timeline rather than treating as optional. For the complete framework, see how to build websites that win and keep clients.
Runvax: A Faster Path to the Client, Not to the Build
A realistic build timeline still depends on landing the right client efficiently in the first place. Runvax finds local businesses with no website in any city and category and drafts your first outreach message — so the weeks you save aren't spent rushing delivery, they're spent finding the next project sooner.