How long does website development take? Industry surveys suggest that a typical small-to-mid-size business website takes around 6–12 weeks from kick-off to launch, while more complex organisational or e-commerce projects often run 12–24 weeks and large enterprise platforms 6–12 months. The biggest variables are content readiness, stakeholder approvals, and integration complexity.
The most common source of friction in a website project is not the agency’s build speed. It is a misalignment of expectations about how long the process actually takes and why it takes that long.
A CEO who says “just get the new website up as quickly as possible” is setting the conditions for a compressed project that cuts discovery, rushes design sign-off, skips user testing, and launches with content that was never quite ready. The site goes live. And then the rework begins at a cost that typically exceeds what proper planning would have required in the first place.
A startup founder who has budgeted three weeks for a new website is about to discover that three weeks get you a template with placeholder content, not a strategic website built around their audience.
A realistic timeline is not a slow one. It is one that builds in the right time for discovery, iteration, content, and testing so that what launches actually works and does not require immediate remediation.
This guide breaks down each development phase with indicative durations, identifies the most common causes of delay, outlines the milestone structure, and provides clients with a practical framework for keeping projects on schedule.
For a detailed breakdown of what happens in each phase roles, responsibilities, and deliverables see our website development process guide. This article focuses specifically on time: how much each phase takes and what eats into it.
What is a website development timeline?
A website development timeline is a structured schedule that maps each phase of a website project to a realistic duration and sequence. It covers discovery, design, development, testing, and launch — and identifies the milestones where client input, approvals, and sign-offs are required. It is the primary tool for managing expectations on both sides.
A timeline is not a Gantt chart for its own sake. It is a shared agreement between the organisation and the agency about what will happen, in what order, and when decisions need to be made. Its value is in making the dependencies visible before the project starts — so that everyone knows which delays have downstream consequences and which decisions cannot be deferred without cost.
Phase-by-phase timeline guide
Phase 1: Discovery and Strategy
What happens: stakeholder interviews, audience definition, competitor analysis, technology selection, KPI setting, and content audit if the project is a redesign.
Indicative duration: 1–4 weeks
This phase is longer for organisations with multiple stakeholders, complex requirements, or significant existing content to audit. It is shorter when the client arrives with clear briefs, documented audience research, and fast internal decision-making.
Client responsibilities: Availability for stakeholder interviews and workshops. Providing existing brand documents, content assets, and analytics access. Defining and agreeing on project success metrics before the next phase begins.
Timeline risk: Slow client response to briefing requests is the most common Phase 1 delay and the most consequential. Every week of delay in discovery shifts every subsequent phase.
Phase 2: Information Architecture and Content Planning
What happens: sitemap development, navigation structure, content inventory, page templates identified, and content responsibility matrix agreed.
Indicative duration: 1–2 weeks
Client responsibilities: Approving the sitemap and navigation structure. Confirming who is responsible for writing, reviewing, and supplying content for each page. Providing source content — existing documents, copy, photography — for use in design.
Timeline risk: Starting design before the content plan is finalised is a pattern that causes significant rework later. Content is a client dependency. The earlier it is locked, the earlier the design can begin on a solid foundation.
Phase 3: UX Design and Wireframing
What happens: wireframes for key page templates, user flow mapping, and prototype development for testing if in scope.
Indicative duration: 1–3 weeks
Client responsibilities: Reviewing wireframes with the right internal stakeholders — not necessarily everyone. Providing consolidated, specific feedback rather than conflicting input from multiple independent reviewers. Signing off on wireframes before visual design begins.
Timeline risk: Multiple rounds of revision are common when stakeholder groups are not aligned before the review phase. The resolution is simple and should be agreed upon before the project starts: one nominated decision-maker for design approvals. Input can come from many people; the sign-off authority belongs to one.
Phase 4: Visual Design
What happens: brand application, component design, style guide development, responsive state design across desktop, tablet, and mobile.
Indicative duration: 2–4 weeks
Client responsibilities: Reviewing designs against the project brief and brand guidelines. Providing consolidated feedback across all stakeholders in a single round. Signing off on design before development begins.
Timeline risk: Visual design is the most emotionally charged phase of a website project. Subjective web design feedback without reference to the brief, user goals, or agreed success criteria produces revision cycles that consume time without improving outcomes. Establish clear feedback criteria before the review begins: Does this serve the user’s goal? Does it reflect the brief? Is this a requirement or a preference?
Changes made after design sign-off during development cost significantly more than changes made during design review. The same logic applies directly to design changes: the further into the project, the more expensive the change.
Phase 5: Development
What happens: front-end build, CMS configuration, back-end logic, integrations, and content entry begin.
Indicative duration: 3–8 weeks
The range here is wide because the variables are significant: custom functionality, the number of third-party integrations, CMS complexity, and content volume all meaningfully affect build time.
Client responsibilities: Delivering final content — copy, images, documents — on schedule. Reviewing content as it is entered for accuracy. Responding promptly to developer queries about functionality or content requirements.
Timeline risk: Late content delivery is the single most common cause of development-phase overruns and is almost entirely a client-side problem. Content that has been agreed in principle but not yet written or approved cannot be entered, designed around, or tested. When content arrives late, the development timeline extends.
Phase 6: Testing and Quality Assurance
What happens: cross-browser and cross-device testing, performance testing, accessibility audit, security review, and user acceptance testing (UAT).
Indicative duration: 1–2 weeks
Client responsibilities: UAT — testing the built site against agreed requirements and defined user journeys. Raising issues in a structured format rather than ad hoc emails. Distinguishing clearly between bugs (things that do not work as agreed) and change requests (new requirements that were not in the original scope).
Timeline risk: The most common cause of timeline extension at this phase is change requests raised during UAT that were not part of the original scope. These are frequently genuine needs that were not surfaced during discovery, which is an argument for thorough discovery, not for accepting unlimited scope changes during testing. Establish a clear change management process before UAT begins.
Performance and accessibility testing at this stage should not be compressed. Industry research shows that even a one-second improvement in page load time can meaningfully increase conversion rates, and sites that meet Core Web Vitals thresholds see significantly lower abandonment rates. Testing time protects this outcome.
Phase 7: Launch
What happens: DNS cutover, final file checks, 301 redirects for any replaced URLs, Search Console submission, GA4 verification, and post-launch monitoring.
Indicative duration: 1–3 days for the technical launch; allow 1 week buffer for DNS propagation and immediate post-launch fixes
Client responsibilities: Formal sign-off before go-live. A communications plan for stakeholders and existing users. Availability during the launch window for rapid feedback on anything that needs immediate attention.
The launch is not the end. The first week post-launch is a monitoring and response period for tracking analytics, watching for crawl errors, checking redirect behaviour, and addressing any issues that the live environment reveals. Explicitly build this window into the project plan.
Indicative timeline summary by website type
| Website Type | Typical Duration |
|---|---|
| Simple brochure site (5–15 pages) | 4–10 weeks |
| Small business site (8–12 pages) | 6–10 weeks |
| Mid-size organisational site (15–50 pages) | 10–16 weeks |
| Complex organisational site with integrations | 16–24 weeks |
| E-commerce or transactional platform | 16–36 weeks |
| Enterprise platform or full rebuild | 6–12 months |
A GoodFirms survey of over 100 web development companies found that most business websites are delivered in 2–12 weeks, with complex portals and web applications typically taking 16–30 weeks or longer, consistent with the ranges above. These are industry benchmarks, not guarantees. Your specific scope, content readiness, and stakeholder availability will determine where your project falls within these ranges.
Planning a website project and need a realistic timeline? Butterfly’s discovery process produces a scoped project plan with a specific timeline before any design or development begins. Request a scoping session →
Website development milestones — what to formally sign off?
Milestones are the formal decision points that advance a project from one phase to the next. They matter because they create shared accountability. The project proceeds when both parties have agreed it is ready to proceed, not when one side assumes the other is satisfied.
| Milestone | Who Signs Off | What It Unlocks |
|---|---|---|
| Discovery complete | Project lead / Marketing Manager | IA and content planning begin |
| Sitemap and IA approved | Project lead | Wireframing begins |
| Wireframes approved | Project lead + key stakeholders | Visual design begins |
| Visual design approved | Project lead | Development begins |
| Content delivered | Client content lead | Content entry and build completion |
| UAT complete | Project lead | Launch preparation begins |
| Launch approved | Project lead / Executive sponsor | Site goes live |
If a milestone is not formally signed off, or if feedback is informal, partial, or ongoing, the project has no stable basis to build the next phase on. Formal milestones are not bureaucracy. They are the mechanism that protects both the agency and the client from the costs of late-stage changes.
What causes website projects to run over time?
Client-side causes
Late content delivery. Consistently reported by agencies as the single biggest cause of project overruns. Content that was supposed to be ready by week four but arrives in week eight does not compress the development timeline; it extends it. Treat content as a parallel workstream with its own deadlines and ownership, not as something to be sorted out once the design is approved.
Slow or conflicting stakeholder feedback. Multiple reviewers without a single decision-maker produce circular revision cycles. The research on approval delays is consistent: too many approvers increase revision cycles three to four times compared with coordinated review structures. Fear of making the wrong call, perfectionism, and unclear ownership all contribute to content circulating endlessly between team members.
Scope changes after sign-off. Every new requirement added after a phase has been signed off has a cost and a timeline implication. In classical SDLC research, late-stage changes cost up to 100 times more than the same changes addressed early. Modern tooling and agile practices reduce but do not eliminate this multiplier. Understand the change management process before the project starts.
Unavailability for UAT. Rushing user acceptance testing or deferring it extends the launch and significantly increases post-launch rework. Build UAT time into your calendar as a hard commitment, not a flexible window.
Agency-side causes
Inadequate discovery. Requirements discovered during development that should have been captured at discovery are expensive to address and typically traceable to weak stakeholder engagement at initiation. A thorough discovery phase is a timeline investment, not overhead.
Underestimated technical complexity. Integrations and custom features often take longer than initial estimates suggest. Thorough technical scoping before development begins reduces, but does not eliminate, this risk.
Unclear change management process. Without a defined process for handling scope changes, scope creep happens by default, quietly extending the timeline and budget without formal acknowledgement.
External causes
Third-party integrations. Dependencies on payment gateways, CRMs, booking systems, and APIs outside either party’s control can introduce delays that neither side anticipated. Identify all integrations at discovery and build dependency management into the project plan.
Hosting and infrastructure setup. Complex or compliance-sensitive hosting environments, particularly for government or healthcare organisations, take longer to configure than standard shared environments.
How to keep your website project on schedule
1. Nominate a single project owner with decision-making authority. Projects with actively engaged sponsors and a clear decision-maker are approximately 40% more likely to finish on time and within budget. Input can come from many people. Authority belongs to one person.
2. Prepare content before design begins. Treat content as a core project workstream not an afterthought. Assign content owners, set deadlines, and track delivery.
3. Consolidate feedback to one round per phase. Collect all stakeholder input before submitting feedback. Multiple rounds of minor comments from many reviewers are significantly less efficient than one round of consolidated, specific feedback from a single decision-maker.
4. Understand the change management process upfront. Know before the project starts how scope changes are raised, how they are costed, and how they affect the timeline. Every accepted change request that lacks a corresponding timeline or budget adjustment is an unacknowledged project risk.
5. Block review time in your calendar in advance. Stakeholder unavailability is often the bottleneck. Reserve time for reviews and sign-offs before the project starts, not when the agency is waiting for feedback.
6. Do not move the launch date without moving the scope. If the deadline is fixed, the scope must flex — not the quality. Compressing quality creates post-launch problems that cost more to fix than the original timeline discipline would have required.
Agile vs waterfall — does the methodology affect the timeline?
Waterfall development follows a strict sequential phase structure, in which each phase is completed before the next begins. Agile development works in iterative sprints, releasing working increments regularly. For most organisational website projects, a structured waterfall or hybrid approach gives clients clearer sign-off points and more predictable timelines; agile is better suited to complex applications or ongoing product development.
In practice, most agency website projects use a hybrid approach: discovery and design follow a waterfall structure with formal sign-offs at each phase; development may use sprint cycles internally, particularly for larger builds. This gives clients the predictability of milestone-based progression while allowing the development team to manage build complexity iteratively.
For a client considering which to specify, waterfall requires upfront clarity and produces predictable milestone timelines. Agile requires higher client engagement throughout and works best when requirements are expected to evolve. For a first-time website build with a fixed launch date, a structured hybrid approach is typically the lower-risk model.
Frequently Asked Questions
Surveys of web development companies suggest a typical business website takes 2–12 weeks to build, while complex portals and web applications can run 16–30 weeks or longer. Content readiness and stakeholder approval speed are the most significant variables, often more so than the agency’s build capacity.
A typical project runs through discovery (1–4 weeks), information architecture (1–2 weeks), UX design (1–3 weeks), visual design (2–4 weeks), development (3–8 weeks), testing (1–2 weeks), and launch (approximately 1 week). Total: roughly 10–24 weeks for a mid-complexity site.
Late content delivery and slow approvals are consistently cited as the top causes. Research indicates that more than half of companies miss deadlines due to approval bottlenecks, with the majority of approval cycle time spent waiting between reviewers rather than actually reviewing content.
Have your content ready before design begins. Nominate a single decision-maker. Consolidate feedback into one round per phase. Agree on a clear change management process before the project starts. These factors not just the agency’s build speed are the primary determinants of how fast a project moves.
Website development milestones are the formal sign-off points that advance a project from one phase to the next: discovery completion, sitemap approval, wireframe approval, design approval, content delivery, UAT sign-off, and launch approval.
A simple website can be built in a few weeks once the content is ready and approvals are in place. Compressing timelines for complex projects typically means cutting scope or deferring testing, which increases the risk of post-launch issues and expensive rework. A faster launch is not always a better launch.
Realistic Website Timelines Are a Project Management Tool, Not a Constraint
The organisations that launch websites on time are not those who compress the process — they are those who plan it properly from the start. A realistic timeline that includes adequate time for discovery, consolidated review cycles, and thorough testing is cheaper, faster, and less stressful than an optimistic timeline that accumulates phase-by-phase delays.
The phase-by-phase guide above gives you the structure. The milestones table gives you the accountability framework. The delay analysis gives you the foresight to address the most common problems before they occur.
What determines whether your project lands on schedule is not primarily the agency’s capacity. It is the quality of your preparation, the decisiveness of your internal process, and the readiness of your content.
Deliver your next website on time and on brief. Talk to Butterfly about a structured, transparent project process that keeps stakeholders aligned and projects on schedule. Get in touch →
