The Website Development Process Explained
Every website development methodology arranges the same phases differently. Understanding the phases themselves — what each produces and what closes it — is more useful than the name of the methodology, because it tells you whether the project is where it should be.
This guide covers the seven phases, typical durations for a mid-sized site, and what a real sign-off looks like at each one.
The seven phases#
Durations here assume a mid-sized custom site with a small team. They stretch with content volume and integrations far more than with page count.
| Phase | Produces | Typical duration |
|---|---|---|
| 1. Discovery | Goals, audience, scope, constraints | 1–2 weeks |
| 2. Structure | Page structure, content model, wireframes | 1–2 weeks |
| 3. Design | Templates, component system, responsive rules | 2–4 weeks |
| 4. Build | Working templates, CMS, integrations | 4–10 weeks |
| 5. Content | Real text, images and data in the system | Runs in parallel — often the longest |
| 6. Test | Functional, cross-browser, performance, accessibility | 1–2 weeks |
| 7. Launch | Live site, redirects, monitoring, handover | 2–5 days |
Phase 5 is the one that overruns. It is drawn as parallel because it should start in phase 2, not because it is small.
What closes each phase#
A phase is not finished because time has passed. It is finished when a specific thing has been agreed, in writing, by someone with authority. Without that, work continues on a foundation that can still move.
- Discovery: a signed scope with an explicit out-of-scope list.
- Structure: an approved page structure and content model, with field names your team understands.
- Design: approved templates for every distinct layout, including mobile and empty states.
- Build: each template demonstrated on staging with realistic content.
- Content: every launch-critical page filled and proofread by a named person.
- Test: an issue list agreed and split into launch blockers and post-launch fixes.
- Launch: a completed pre-launch checklist and confirmed access handover.
Waterfall, agile, or something in between#
The genuine difference is when scope is fixed. Fixed-scope projects price precisely and handle change badly; iterative projects handle change well and cannot promise a fixed total. Most website work sits in between: fixed scope for the launch, iterative afterwards.
| Fixed scope | Iterative | |
|---|---|---|
| Price | Known up front | Rate per sprint or per month |
| Change | Formal change request, repriced | Absorbed by reprioritising the backlog |
| Best for | Clear, stable requirements | Evolving products and unclear requirements |
| Risk to you | Paying for something that no longer fits | Cost drifting without a hard stop |
| Needs from you | Decisions up front | Continuous availability to prioritise |
Beware fixed price with vague scope. It is the worst combination: the developer protects the margin by interpreting ambiguity narrowly, and every clarification becomes a negotiation.
Where the process usually goes wrong#
The same four failures account for most overruns, and none of them are technical.
- Design approved against placeholder content. Real copy arrives at double the length and the layout is rebuilt.
- Integrations discovered late. "It also needs to talk to our stock system" in week eight is a new project, not a change.
- No single decision-maker. Feedback arrives from five people, two of them disagree, and nobody has authority to settle it.
- Testing treated as a phase rather than a habit. Bugs found in week ten that were introduced in week three cost several times more to fix.
Frequently asked questions
How long does a typical website take?
A template-based small site is two to four weeks. A mid-sized custom site is typically three to five months end to end. Stores and applications run longer. The variable that moves these most is not complexity of code but availability of content and speed of decisions on the client side.
Can phases overlap?
Some should. Content should start during structure, and testing should run throughout the build rather than only at the end. What should not overlap is design and build of the same template — building against a design that is still moving guarantees rework, and it is the most common source of "we already built that" arguments.
What if we need to change something mid-project?
Expect to, and agree the mechanism in advance: who can request a change, who prices it, and whether it moves the launch date. Small changes absorbed silently are how a project drifts a month without anyone being able to say when it happened. A written change log solves most of this.
Should I pay per phase?
Milestone payments tied to deliverables you can inspect are the fairest structure for both sides — typically a deposit, then payments at design approval, build completion and launch. Avoid paying entirely up front, and avoid paying entirely on completion, which pushes all the cash-flow risk onto the developer and usually costs you more.
website development processweb development phaseswebsite project stagesagile web developmentwebsite timelinewebsite development methodology
