The website development process, end to end

A website build is not one undertaking called “building a website.” It is a website development process made of fourteen distinct stages, each with its own inputs, its own output and its own owner — running end-to-end from the first discovery conversation to launch and beyond. Most of what feels like an opaque, unpredictable process to a first-time client is actually a fixed sequence that every competent supplier runs, whether or not they ever say the stage names out loud.

Knowing the sequence matters for a practical reason: it tells you whose delay is actually causing a slip. A client who has not supplied content is not the same problem as a designer who has not delivered concepts. A supplier who blurs the two together — usually to avoid naming which side is behind — is the person this page is written to stop.

The fourteen stages of the website development process, in order

Stage	What it produces	Who is usually responsible
Discovery	A shared understanding of the business, its audience and its goals	Supplier leads, client supplies information
Scoping and estimating	A defined scope and a quote against it	Supplier
Content collection	The words, images and data the site will actually contain	Client supplies, supplier specifies what’s needed
Wireframing	The structure of each page, before any visual design	Supplier
Design concepts	One or more visual directions for the client to choose between	Supplier
Design sign-off	Client approval of a specific visual direction, in writing	Client approves, supplier records
Build	Working code — markup, styling, functionality	Supplier
Content population	The approved content loaded into the built site	Supplier, using client-supplied content
Internal review and QA	A site checked against a fault list before the client sees it	Supplier
Client user acceptance testing	Client confirmation the site does what was agreed	Client tests, supplier fixes
Pre-launch checklist	A verified go/no-go before the DNS is switched	Supplier
Launch day	The site live on its real domain	Supplier
Post-launch warranty period	A defined window where launch defects are fixed at no extra cost	Supplier
Handover and training	Client control of logins, content editing and ongoing decisions	Supplier delivers, client receives

Each row links to its own page, because each stage has enough real detail — what commonly goes wrong there, what a client should expect to see, and what a supplier padding the process looks like — to earn its own document rather than a paragraph. The visual design stages (concepts and sign-off) and the technical build stages are separated deliberately: a designer working in a visual tool and a developer writing the markup, styling and functionality are frequently different people or different skill sets even inside the one agency, and treating them as a single “design and development” step is where responsibility gets lost when something is late.

Why the stages are ordered the way they are: what each phase depends on

Each stage depends on the one before it in a specific way, not just a conventional one. Wireframing cannot usefully start before scope is defined, because a wireframe is a structural answer to a scope question. Visual design cannot usefully start before content collection has at least begun, because a design built for placeholder text routinely breaks when real sentences of a different length are dropped in. The build stage — the point at which working code, and whatever technologies the supplier has chosen, actually get written — cannot start before design sign-off, because building against an unapproved design risks paying twice for the same page. This is the actual reason a supplier resists starting two stages in parallel when a client is in a hurry. It is not bureaucracy — upstream changes reliably cascade into rework downstream.

The client’s role and the supplier’s role in the web development process

Every stage above sits mostly with the supplier or mostly with the client, and the phase where that balance shifts is where most projects actually slow down. Discovery, wireframing, visual design and the technical build are supplier-led — designers and developers produce; the client’s role is to approve, not to produce. Content collection is the opposite: it is client-led, and no amount of supplier process compresses a stage that depends on someone else’s calendar. A web development team that names this split at the start of a project, rather than discovering it mid-build, is telling you it has actually run this process before.

Where the website development process most commonly breaks down

Three points account for most of the friction reported in project retrospectives across the industry, and none of them is the stage most clients expect.

Content collection, not design, is the single most common cause of a slipped timeline. A supplier can hold a design or build schedule steady because it is their own labour on their own calendar; they cannot make a client’s product descriptions, staff bios or photography arrive on a date the client does not control.

Design concepts are where padding happens. Some suppliers advertise a generous number of concepts to sound accommodating, then absorb the cost by compressing every later stage, or by treating the “extra” concepts as thin variations of the same idea rather than genuinely different directions. More concepts are not automatically better service — see design concepts, and how many you should expect for what a concept actually needs to contain to count as one.

Client user acceptance testing is where the least real scrutiny tends to happen, because by this stage the client is tired of the project and eager to launch. Treating UAT as a formality rather than a genuine check is the single easiest way for a defect to reach a live, public site. See client user acceptance testing for what is actually worth checking and how.

What this page does not cover about cost or a specific project

This page describes the sequence and the purpose of each stage. It does not state what any stage should cost — cost depends on scope, page count and platform, and is covered properly on what drives the cost of a website rather than estimated here. It also does not evaluate a specific supplier’s quote or contract; for that, see the questions worth asking before you sign one, covered elsewhere on this site.

How to use the fourteen stage pages

Each linked page below states, in plain terms: what the stage is actually for, what a client is typically asked to do or approve at that point, what a rushed or padded version of that stage looks like, and where it fits against the stages either side of it. Read the stage your project is currently at, and the one immediately after it, before your next meeting with a supplier — it is the fastest way to walk into that conversation knowing what should be on the table.

If you are choosing a supplier rather than mid-build with one already, the process described here is also a fair question to ask directly: walk me through these fourteen stages as you run them, and see how specifically they can answer. A supplier who has genuinely run this process many times will name the same friction points named on this page, in their own words, without being prompted. General information: read website design services for what is typically included in a build engagement, and website design company for what to expect from the business relationship around it. For where this process sits inside web design as a discipline, start with web design in Australia.