Where the weeks go in a website rebuild

Projects rarely overrun because the building took longer than expected. They overrun because of content, decisions and approvals, which are the parts nobody schedules.

Talk to us about your rebuild

The technical build is usually the predictable part. Delay comes from content that was never written, decisions with no clear owner, and approval rounds without a deadline. Plan those explicitly, name one decision-maker, and set dates for content and approvals rather than for the build alone.

The stages, and which ones slip

A rebuild has a predictable shape, and the slippage is concentrated in a couple of places that are usually the client's responsibility rather than the supplier's.

  • Measurement and planning: short, and skipped at your peril.
  • Content: the largest source of delay in almost every project.
  • Design: predictable if the decision-maker is clear.
  • Build: usually the most reliable stage.
  • Review and approval: slips whenever no deadline exists.
  • Launch and redirects: short, provided the map was prepared.
  • Post-launch fixes: continuous, and should be planned for.

Content is where projects go to wait

The single most common reason a site is finished and not launched is that somebody was going to write the text. Weeks pass, then months, and the design that was approved in spring goes live in autumn.

Decide at the start who writes it, when each piece is due, and what happens if it is late. If it is your responsibility, block time for it as you would for anything else that stops a project.

One decision-maker, named

Approval by committee adds weeks per round and produces designs that satisfy nobody. Name one person who can approve, and let everybody else advise.

Where several people genuinely must agree, collect their input before the round rather than during it, and set a deadline for responses. Silence past the deadline should count as agreement, and everybody should know that in advance.

Limit the rounds

Agree how many rounds of revision are included and what a round means. Endless small changes are the other great consumer of time, and each one feels too minor to refuse.

Two rounds with consolidated feedback is usually enough. Feedback arriving as a stream of individual messages over three weeks is the pattern that stalls projects.

Do not launch on a Friday

Launch early in the week, in the morning, when everybody involved is available for the rest of the day. Problems appear in the first hours, and the ability to fix them immediately matters.

Also avoid launching immediately before your busiest season or a holiday. The weeks after launch need attention, and that is exactly what a busy period removes.

Plan for the month after launch

A launch is not the end of the work. The month afterwards contains redirect fixes, small corrections, indexing checks, and the first evidence about whether anything improved.

Projects that treat launch as the finish line leave those undone, and the small unresolved problems become permanent features of the site.

How Licheo schedules a rebuild

Content is part of the work rather than the client's homework, which removes the largest source of delay before it can occur.

Redirects are prepared before launch, launches happen early in the week, and the month afterwards is planned rather than assumed.

Part of a larger guide

This page is one part of Redesign and revenue. The other parts:

Questions people ask

How long does a website redesign take?
The build is usually the predictable part. The timeline is decided by content, decisions and approvals, so a project with those planned finishes far sooner than one where they are assumed.
What causes most delays?
Content that was never written, decisions with no clear owner, and approval rounds with no deadline. All three are usually on the client side and all three are avoidable by scheduling them.
How many rounds of revision should I expect?
Agree the number in advance and consolidate feedback into each one. Two rounds is usually enough; a stream of small individual changes over weeks is what stalls projects.
When should I launch?
Early in the week, in the morning, with everybody available afterwards, and not immediately before your busiest season or a holiday. Problems appear in the first hours and need attention.
What happens after launch?
Redirect fixes, small corrections, indexing checks, and the first real evidence about whether anything improved. Plan for that month, or its unresolved problems become permanent.

A rebuild that does not stall

Content included rather than set as homework, redirects prepared before launch, and the month afterwards planned.

Talk to us about your rebuild Read the full guide