Website development timelines: stages and dependencies

A Monday start date does not mean development can begin. Confirm the launch goal, page scope, decision owner, materials and access. If important inputs are unknown, discovery and an agreed plan become the first deliverables.

An estimate should state its assumptions: copy arrives before design approval, a test integration exists and feedback is consolidated. A week count without these conditions suggests precision the project does not have.

Define an output for each stage: journeys, prototype, visual system, working build and accepted release. Record which decisions are settled and how later changes are handled. Small sites can combine stages; complex portals benefit from frequent demonstrations with realistic data.

Copy preparation, environment setup and API design can run together. Development can begin once core components are approved, while secondary screens continue. This needs stable contracts between teams.

Starting every task against an unsettled structure creates rework. Parallel work is useful when one team is not repeatedly invalidating another team’s output.

Delays can originate anywhere: unclear requirements, technical constraints, missing content or slow review. Track the dependency, owner and next decision rather than assigning blame.

“Choose photography, licensed imagery or a launch without this section by Thursday” is more actionable than “waiting for pictures”. A short blocker log makes trade-offs visible.

Reserve time for forms, real devices, redirects, analytics and handover. External services and domain configuration also affect the switch. With a fixed deadline, agree on the minimum release and deferred work in advance.

Assign someone to watch availability, enquiry delivery and errors after launch. The team needs to know what is ready and how to recover, not simply when development stops.