The Phases, and What Happens in Each
A redesign isn't one block of time, it's a sequence. Discovery and strategy come first: understanding your goals, auditing the current site, and planning structure. Then design turns that into layouts and a visual system. Build converts approved designs into a working site. Finally, testing and launch make it live safely.
Each phase depends on the one before it, which is why rushing the front end tends to cost time later. Getting the structure and design right before the build saves rework once code exists.
- Discovery and strategy: audit, goals, and site structure
- Design: wireframes, then visual layouts, with your review
- Build: turning approved designs into a responsive, working site
- Content: migrating or creating the words and images
- Testing and launch: QA, redirects, and going live
What Speeds It Up or Slows It Down
The biggest schedule variable usually isn't the building, it's the back-and-forth. Timely feedback at each review, and content that's ready when the build needs it, keep a project moving. The most common cause of delay is waiting on client-side approvals or copy that isn't finished yet.
Scope matters too. More pages, custom features, and integrations naturally take longer than a focused refresh. And a platform migration adds steps, content moves, redirect mapping, testing, that a same-platform redesign doesn't.
- Prompt feedback at each review keeps the schedule on track
- Having content and assets ready avoids the most common delay
- More pages, features, and integrations extend the timeline
- Platform migrations add migration and redirect steps
- Clear decisions up front prevent mid-project rework
Setting Realistic Expectations
We won't quote a timeline before we understand your scope, because a real schedule depends on the size of the project and how the collaboration flows. What we can promise is a phased plan with clear milestones, so you always know what stage we're in and what's needed next.
On a free consultation, we'll map your project into phases and give you a realistic timeline for your specific redesign, including where your input will be the pacing factor, so there are no surprises.
- A phased plan with clear milestones from kickoff to launch
- Honest identification of where your input drives the pace
- A timeline tied to your actual scope, not a generic promise
- Built-in time for testing and a controlled launch
More on website redesigns
Frequently asked questions
Can you give me a timeline before we start?
We can give you a realistic one after a short scoping conversation, but not before. The schedule depends on how many pages and features are involved, whether it's a migration, and how quickly feedback and content come back. A number given before we understand those would be a guess, and guesses on timelines tend to disappoint.
What's the most common reason a redesign runs late?
Waiting on the client side, usually feedback on designs or final content that isn't ready when the build needs it. The building itself is fairly predictable; the collaboration is what varies. The single best thing you can do to keep your project on schedule is respond promptly at review points and have your content lined up.
Can a redesign be rushed if I'm in a hurry?
Some phases can be compressed, especially a focused, smaller-scope project. But skipping strategy or testing to save time usually creates problems that cost more time later, like a launch that hurts your SEO. If you have a hard deadline, tell us up front and we'll scope the project to fit it honestly rather than cut corners quietly.