A realistic schedule

For a typical 15–30 page site for an established business, the shape looks like this.

  • Weeks 1–2: diagnosis. Audit, analytics review, interviews, competitive analysis.
  • Weeks 3–4: direction. Positioning, sitemap, message hierarchy, art direction.
  • Weeks 5–9: design and content, running together rather than in sequence.
  • Weeks 9–13: build, with design continuing on secondary templates.
  • Weeks 13–15: quality assurance, redirects, analytics, accessibility and content loading.
  • Week 16: launch, then a monitored fortnight.

The four causes of nearly every delay

After enough projects the pattern is consistent, and none of the four is a design problem.

Content is the first and largest. A client who agrees to supply copy in week three and delivers in week eleven has moved the launch by eight weeks, not by the two they think. The second is approval structure: if six people must agree and none can decide, every round takes a fortnight. The third is photography, which depends on weather, season, occupancy and availability, and cannot be compressed. The fourth is scope added mid-project — each addition is small, and collectively they are not.

How to protect the date

Name one decision-maker with genuine authority. Agree that content is produced within the project rather than supplied to it. Book photography before the design starts, not after. Agree that anything new goes on a post-launch list rather than into the current scope.

These four commitments do more for a launch date than any amount of project management software.

Can it be done faster?

Yes, when there is a genuine reason — a funding announcement, an opening, a rebrand with a fixed date. Compression works by reducing scope, not by working harder: launch the essential pages properly and add the rest afterwards.

What does not work is compressing the diagnosis. Skipping the first two weeks reliably costs more than two weeks later, because everything built on an unexamined assumption has to be revisited.

What happens after launch

Launch is a threshold, not an ending. The fortnight afterwards should be actively monitored: search performance against the old URLs, form submissions actually arriving, analytics recording correctly, and real user behaviour against what the design assumed.

Most of the value of a redesign is realised in the months after launch, through publishing and measurement. Plan for that period before you reach it.