How Long Does It Take to Build a Website? A Phase-by-Phase Guide

Website Build Timelines by Type — The Reference Table

Before the phase-by-phase breakdown, this is the reference timeline most people are searching for:

These timelines assume a professional agency working with clear scope and responsive client feedback. A freelancer on a simple project can deliver faster; an offshore team with communication latency will typically deliver slower regardless of headline promises.

1 Discovery and Scoping (Days 1–5)

Discovery is the phase most clients want to skip and the phase that determines whether the rest of the project succeeds or fails.

What happens in discovery

The agency conducts a structured interview covering: business objectives (what does this website need to achieve commercially?), target audience (who is the site for, and what do they need from it?), competitive landscape (what are the benchmark sites and the gaps to exploit?), technical requirements (CMS, integrations, performance targets), and content inventory (does the content exist, who is writing it, and in what format will it be delivered?).

The output is a written Discovery Brief — a document that becomes the contract of understanding for everything that follows. A properly executed discovery brief prevents the two most expensive problems in web design: building the wrong thing correctly, and changing direction mid-build.

Where discovery delays happen

The primary cause of discovery delays is the client stakeholder not being available. A project that needs sign-off from three people will stall every time one of them is unavailable. At Hawd Design, we ask that clients nominate a single point of contact with authority to make decisions — not a committee. This single structural choice reduces discovery time by approximately 40%.

Discovery timeline by project type

• Landing page: 1 day (scoping call + brief)
• Starter website: 2–3 days
• Business website: 3–5 days
• Enterprise: 1–2 weeks (may include a paid Discovery Phase as a separate engagement)

2 Information Architecture and Wireframes (Days 3–10)

Information architecture (IA) defines the site's page structure, content hierarchy, navigation, and user flow. Wireframes translate that structure into schematic page layouts — showing where each content block sits, how the page sections relate, and what the user journey through the site looks like — without applying any visual design.

Why wireframes matter before design

A client who reviews wireframes before design begins can change the page structure, add or remove sections, or rethink the navigation without losing any design work. A client who first sees the structure embedded in a finished visual design is making change decisions that either require significant rework or get suppressed because the sunk cost of the design makes changes feel expensive.

Professional agencies present wireframes as interactive mockups — clickable in a browser so the client can experience the user flow rather than reading static flat diagrams. We use Figma for all wireframe delivery.

Common IA decisions that affect timeline

• How many pages and what hierarchy (flat vs. deep navigation)
• Whether to include a blog module (requires CMS content type configuration)
• The contact and conversion architecture (form fields, thank-you page, CRM integration)
• Whether service or product pages follow a template or are individually designed

IA timeline by project type

• Starter website: 3–4 days
• Business website: 5–7 days
• E-commerce: 5–8 days (product taxonomy and category architecture add scope)
• Enterprise: 1–2 weeks

3 Visual Design (Days 7–21)

Visual design is where the wireframe structure receives typography, colour, imagery, spacing, and the aesthetic identity of the brand. The output is a high-fidelity Figma prototype — interactive, responsive, demonstrating hover states, mobile layouts, and micro-interactions — that functions as the visual specification for development.

The standard design deliverables

• Desktop and mobile mockups for every page type
• Component library: buttons, forms, cards, navigation states, footer
• Typography scale: heading hierarchy, body text, captions, labels
• Colour system: primary, secondary, accent, neutral, semantic (success, warning, error)
• Interactive prototype: clickable in Figma, with transitions demonstrating scroll and hover behaviour

Phase-locking: the mechanism that prevents scope creep

The design approval is phase-locked. Once the client approves the design, it becomes the development specification. Changes requested after design approval are change requests — priced and agreed before execution.

This is not bureaucratic rigidity; it is the mechanism that makes fixed-price projects possible. An agency that accepts unlimited post-approval design changes on a fixed-price contract is either padding the original price to absorb them or losing money. Phase-locking creates a clear boundary that protects both parties.

What causes design to run long

The most common cause of design overrun is multiple stakeholders with conflicting opinions reviewing the same design simultaneously. The arbitration of internal disagreements is not the agency's responsibility to manage — it is the client's. Single point of contact matters here just as much as in discovery.

The second most common cause: insufficient brand material from the client — requesting the agency design a website without providing logos in vector format, brand guidelines, or photography leads to design decisions made in a vacuum that are later overturned.

Design timeline by project type

• Starter website: 5–8 days
• Business website: 8–12 days
• E-commerce: 8–14 days
• Enterprise: 2–4 weeks

4 Development (Days 14–42)

Development converts the approved Figma design into functional code. In a well-run project, development begins while design is being finalised — the agency starts building the CMS structure, the page templates, and the component library as soon as the design direction is confirmed, even before full design approval.

What happens in development

• HTML/CSS build: semantic markup, responsive CSS, animation and transition implementation
• CMS setup: content types, custom fields, user roles, editorial interface
• JavaScript: interactive components, form handling, CMS content loading
• Third-party integrations: analytics (GA4), CRM, booking systems, payment gateways, live chat
• Performance optimisation: image compression pipeline, CSS/JS minification, lazy loading, Core Web Vitals tuning
• Structured data: schema.org JSON-LD for all relevant page types
• Accessibility: WCAG 2.1 AA pass — keyboard navigation, ARIA roles, colour contrast, focus indicators

The tech stack decision and its impact on timeline

A WordPress build adds 2–4 days for CMS configuration but delivers a client-editable interface that most non-technical users can manage. A headless Next.js build is faster on front-end performance metrics but adds development time and requires a separate CMS (Sanity, Contentful, or similar). A Shopify build front-loads time in theme and app configuration but is constrained by Shopify's architecture for custom functionality.

At Hawd Design, we recommend the stack based on the client's content management requirements, performance targets, and expected lifespan — not based on what we find most convenient to build.

What causes development to run long

Integration complexity is the primary development overrun cause. A contact form that submits to an email is a 2-hour task. A contact form that submits to HubSpot, triggers a CRM workflow, sends a confirmation email, and updates a Slack notification channel is a 2-day task. Integrations not specified in discovery consistently produce scope creep in development.

The second cause: content not being ready when development needs it. A CMS built without content cannot be QA tested. Pages built with placeholder text cannot be checked for layout integrity across real content lengths. Content provision is a client deliverable — late content delays development by the same number of days the content is late.

Development timeline by project type

• Starter website: 8–12 days
• Business website: 12–18 days
• E-commerce Starter: 12–20 days (catalogue upload, payment integration)
• Enterprise: 3–8 weeks

5 Content, QA, and Launch (Days 35–56)

Content loading (3–5 days)

If the client is providing content, it must be loaded into the CMS before QA can begin. Content loading is frequently the phase where client-side delays have the greatest impact on the overall timeline — because it sits immediately before launch, so a 1-week content delay translates directly to a 1-week launch delay.

We provide a Content Loading Guide for every project: a document that tells the client exactly what content goes in which field, in what format, and at what character length.

QA (3–5 days)

Quality assurance covers:

• Cross-browser testing: Chrome, Firefox, Safari, Edge — on both Windows and macOS
• Cross-device testing: iOS and Android mobile, tablet, desktop at multiple viewport widths
• Core Web Vitals: LCP, INP, and CLS measured on Lighthouse and PageSpeed Insights; target LCP < 2.5s on mobile
• Accessibility audit: Axe automated scan, keyboard navigation test, NVDA screen reader test, colour contrast verification — WCAG 2.1 AA
• Structured data validation: Google Rich Results Test for all schema types
• Form testing: All submission paths tested, including error states and confirmation emails
• Analytics: GA4 event tracking verified on staging

Staging review (2–3 days)

The client reviews the complete website on a staging server — a live, functional version of the site at a non-public URL — before production deployment. Changes at this stage are within scope if they are corrections (content that differs from what was supplied, elements that differ from the approved design). Changes that are new requirements or preference changes are change requests.

Production deployment (1 day)

DNS propagation, SSL certificate provisioning, analytics configuration, search console submission, and sitemap submission. For WordPress builds, this includes database migration from staging to production and cache configuration. For Shopify, this includes domain connection and payment gateway live-mode activation.

The Real Bottlenecks — Why Websites Run Late

In 30 years of delivering website projects across the UK, DACH, and English-speaking markets, the same patterns cause delays. They are almost never the agency's development speed — they are almost always these:

1. Feedback cycles measured in weeks, not hours A project with 24-hour feedback turnaround finishes on or ahead of schedule. A project where the client reviews a design mockup "when I get a moment" and responds after 10 days has extended its timeline by 10 days. Every feedback cycle adds the client's response time to the project calendar.
2. Copy provided at the last minute or not at all The content for a website is a client deliverable. A 5-page website needs approximately 3,000–5,000 words of copy. If that copy does not exist when the CMS is ready to receive it, the project waits. We ask for all final copy before development begins — or, if the client is using our copywriting service, we schedule the copy delivery into the project plan.
3. Stakeholder alignment not managed client-side "My partner has a different opinion about the design" — raised in week four — is a project-ending delay if the partner's opinion materially changes the agreed scope. Discovery and design approval should include all stakeholders who have veto power. If someone with decision authority has not reviewed and approved the design, the design is not approved.
4. New requirements introduced mid-build "Can we add a booking system?" raised in week six of an eight-week build is not a scope change the agency can absorb without extending the timeline. Any new requirement introduced after design approval requires a change request — timeline extension, price adjustment, or both.
5. Integration dependencies outside the agency's control Third-party APIs (CRM, payment processor, booking system) have their own documentation, authentication flows, and sandbox environments. An integration that requires a two-week wait for API credentials from the client's CRM provider adds two weeks to the timeline regardless of the agency's velocity.

What You Can Do to Keep Your Project on Schedule

These are the specific actions that make the biggest difference to project timeline:

Before the project starts

• Nominate a single decision-maker with authority to approve design and content
• Gather all brand materials before the kick-off call: logo in SVG or AI format, brand colour codes, any existing guidelines, and all existing photography
• Write or commission all website copy before development begins, or engage the agency's copywriting service with agreed delivery dates

During the project

• Commit to 24-hour turnaround on review requests — if you cannot review within 24 hours, tell the agency so they can schedule other work rather than waiting
• Consolidate feedback from all stakeholders into a single submission — not sequential rounds from different people
• Resolve internal disagreements before sending feedback to the agency

At design approval

• Confirm that every stakeholder with veto power has reviewed and approved the design before giving written approval
• Be specific about what you are approving: "I approve this design to proceed to development" is different from "this looks good to me — I'll show the others"

Hawd Design Timelines in Practice

Our standard project timelines, based on actual completed projects:

All timelines are specified in the contract. We have delivered ahead of the contracted timeline on 71% of projects where the client maintained the agreed feedback velocity. The projects that ran late did so for the reasons described above — not because of development capacity issues.

→ View our web design packages and pricing
→ How our project process works