Most projects take 4–8 weeks from kickoff to launch. That’s the typical range for a standard five-page brochure site. A full business site in the 10–20 page range runs 4–12 weeks, with the spread coming down to feedback speed, content, and testing rather than the build itself. Anything over 20 pages, or with custom functionality, moves into 8–16 week territory. E-commerce builds typically run 8–16 weeks too, mostly because product data entry and testing add time that has nothing to do with design.
Those are ranges, not guarantees. A site with content ready on day one and fast feedback lands at the bottom of its range. A site where content arrives in pieces over six weeks lands at the top, or blows past it entirely.
This article is specifically about new builds from scratch. If you’re redesigning a site that already exists, the timeline looks different. See our complete guide to redesign timelines instead, since rebuilding around existing content and structure isn’t the same project as starting from nothing. Confusing the two is exactly how expectations get set wrong before a project even begins.
Why the range is wide even within one category isn’t mysterious once you break it down. Two five-page sites can take very different amounts of time depending on whether the client has final copy ready on day one or is still deciding on messaging in week three, whether photography needs to be sourced or is already sitting in a folder, and how many people need to sign off before a page is considered approved. The page count sets the floor. Everything else determines how close to that floor, or how far past it, the project actually lands.
How to read a timeline promise from any agency
If a quote promises a firm launch date before requirements are even discussed, that’s worth treating with some skepticism regardless of who’s giving it. A realistic timeline should come with a range and a list of what has to happen on your end to hit the low end of it, not a single fixed date that assumes everything goes perfectly and nothing on your side slips.
Timeline by project size
| Project type | Typical range | What drives the upper end |
| 5-page brochure site | 4-8 weeks | Feedback frequency and speed |
| 10-20 business page website | 4-12 weeks | Feedback frequency and speed, content generation and testing. |
| 20+ page or custom build | 8-16 weeks | Feedback frequency and speed, content generation and testing. |
| E-commerce | 8-16 weeks | Feedback frequency and speed, content generation and testing. |
These numbers should come from your own delivery history rather than an industry average, because your process, team size, and typical client are what actually determine your range, not a generic benchmark that has nothing to do with how you work.
Where the time actually goes
Every build moves through the same six phases, roughly in this order: requirements and planning, design, development, content integration, testing and QA, and launch.
Requirements and planning is where the site’s structure, page list, and functionality get locked. It’s tempting to rush this because nothing visible has been produced yet, but a vague brief here is what causes rework two phases later.
Design usually takes up the front third of the timeline alongside requirements, since nothing else can meaningfully start until direction is agreed on. This is also the phase where most rounds of client feedback happen, which is why consolidating it into fewer, clearer rounds has an outsized effect on the overall schedule.
Development is typically the largest single block of time on any project past a handful of pages, and it’s the phase least visible to a client. That’s exactly why status updates matter here even when there’s nothing new to look at yet.
Content integration is where copy and images actually get placed into the built pages, and it’s the phase most dependent on the client rather than the agency.
Testing and QA get compressed the most when a project is running behind schedule. That’s exactly the phase you don’t want compressed, since it’s where accessibility and technical SEO issues get caught before launch instead of after it, when they’re far more expensive to fix.
Launch itself is usually quick on a straightforward site, but it’s not instant on anything involving DNS changes, email migration, or third-party integrations, all of which have their own timing outside your agency’s direct control.
Rough phase breakdowns by percentage of total timeline are useful to share here once you have real numbers to plug in from your own delivery history. They help a prospective client understand where their own project is likely to spend most of its time, and why “just start building” isn’t actually the fastest path to launch.
The three things that cause delays
Content that isn’t ready. Design and development can start on placeholder text, but a site can’t launch on it. Projects stall hardest at the exact point everything else is finished and the client is still writing copy or waiting on photography that was supposed to be ready weeks earlier.
Feedback arriving piecemeal. One round of consolidated feedback from everyone who needs to sign off moves a project forward cleanly. Feedback trickling in from three different people over three separate weeks doesn’t just slow things down, it usually contradicts itself, which means redoing work that was already approved once, sometimes twice.
Scope changes mid-project. Adding pages, swapping functionality, or resetting the design direction after approval are all reasonable things for a client to want. They’re just not free, and they don’t happen instantly. See our website launch checklist for what actually needs to be locked down before a scope change can be absorbed without pushing the date.
Each of these three shows up more often than any technical problem does. A slow CMS or a tricky integration might cost a project a few days here and there, but content, feedback, and scope are what actually move a launch date by weeks. That’s worth knowing if you’re trying to figure out which part of a project to get ahead of first.
What you can do to move faster
None of this is complicated, but it’s the difference between hitting the bottom of a range and blowing past the top of it:
- Have content, copy, images, logos, brand assets, ready before kickoff, not promised for “next week.”
- Consolidate feedback from every stakeholder into a single round instead of letting it trickle in over days.
- Name one decision-maker who has final say, so approval doesn’t loop through five people with five opinions.
- Book review calls on the calendar in advance, rather than scheduling them reactively once a milestone is already hit. Our client onboarding checklist and project plan template are built around exactly this: getting the things that cause delays sorted out before they become delays, rather than managing them after the fact.
What a rushed timeline costs you
Compressing a timeline doesn’t make the work smaller. It makes something get skipped. Usually it’s QA; our full checklist covers what should be tested before launch, not discovered after it. Accessibility review and technical SEO configuration are the other two things that quietly get cut when a deadline is fixed but scope isn’t, and both are considerably more expensive to fix retroactively on a live site than to do properly before launch.
If speed genuinely matters more than anything else on a specific project, a simpler responsive build with a tighter page count is a better lever to pull than skipping steps on a larger one. Cutting pages is a real trade-off you can make deliberately, with full knowledge of what you’re giving up. Cutting QA is a trade-off that gets made for you, later, usually at a worse time: after launch, when a bug or an accessibility gap is live in front of your actual customers instead of caught in a test environment where fixing it costs nothing but time.
If a launch date and a full feature list both feel fixed and non-negotiable, something else on the project has to give, and it’s worth deciding in advance what that is rather than finding out by accident three weeks before launch.
