HowLongDoesaWebsiteRedesignActuallyTake?

Honest timelines by project size, what actually causes delays (it's almost never the design), and when we say yes to a rush and when we don't.

Design and build are rarely what makes a redesign slow. Reviews are. Here are the timelines, and then the honest version of where they go wrong.

The short answer

A refresh, where the structure stays and the visual layer changes, is usually two to four weeks.

A full redesign of a normal marketing site is usually eight to twelve weeks from kickoff to launch, assuming content exists or gets written on schedule.

Complex projects, meaning two languages, a large page count, real integrations, or a brand that has to be resolved first, run four to six months. Most of the extra time is not production. It's decisions.

What the phases actually are

Discovery comes first, and it's where we work out what the site is supposed to do. If the brand needs work, that goes next, because you can't lay a good site on top of an unresolved identity.

Then content, sitemap and wireframes: the structure of the thing, before anyone worries about how it looks.

Then visual design, which we build alongside the front end rather than as static desktop and mobile files handed over for someone else to interpret. Sometimes that's custom HTML, sometimes Framer. Either way you get something you can open and click, because motion and behaviour are part of the design and you can't review them in a flat mockup.

Doing design and build together is also what compresses the schedule. There's no handoff phase where a developer reinterprets a picture.

What actually causes delays

Review rounds. Almost always review rounds.

Nitpicky back-and-forth on details that don't change outcomes. Extra rounds nobody scoped. And in larger companies, work going up the chain and back down, which routinely takes weeks per pass and has nothing to do with anyone's ability.

So we budget for it based on how big your team is. If we're working with an enterprise, we know review cycles will be long and we build generous buffers in from the start. A schedule that assumes instant approvals isn't optimistic, it's wrong, and it makes everyone feel behind from week two.

The second cause is content. If nobody is named as the writer with a date attached, the launch slips. Every time.

"We need it in six weeks"

We can try, and we often can't promise. Production speed isn't the constraint anymore. We use AI heavily through design and build and could genuinely turn work around in days if the situation demanded it.

The problem is what a rush does to everything around it. It means shifting priorities off other projects, and it usually collides with the fact that the client still needs five days to review each stage. You compress our half of the timeline to nothing and the calendar barely moves, because the reviews didn't compress.

We do take genuinely urgent enterprise work and we do deliver it. What tends to happen is that the delays then arrive on the client side anyway, and everyone ends up in crunch. That isn't a healthy way to work and it isn't how you get good decisions.

If the date is real, say why. A funding announcement, a trade show, a product launch. A real reason lets us phase the work so the pages that matter for that date ship first and the rest follows.

How to make it faster, for real

  • Name one approver who can say yes without convening a meeting
  • Collect feedback from everyone, resolve the contradictions internally, then send one consolidated set
  • Have the content ready, or agree upfront that we write it
  • Book the review slots in the calendar at kickoff, before anyone's diary fills up
  • Settle the brand before the website starts, not during it
  • Launch in phases: core pages first, the long tail after

Most of the preparation that saves weeks happens before kickoff. Here's the checklist we work through before a redesign starts.

Get a schedule that matches your team

Tell us the date that matters and how many people need to approve, and we'll tell you whether it's achievable before you commit to it. See how we scope and run a website redesign.

Hitomi Abiko

Author

Hitomi Abiko

ReadMore