The annual pattern is predictable and entirely preventable. July and August are quiet. September brings the first emails: “We’d like to refresh the website. Can you deliver by Christmas?” October brings panic. November brings frustration. December brings disappointment, when the carefully planned autumn website launch slips into January because no one understood how timelines actually work.
This article gets written every year because the cycle repeats. Organisations wait too long and then discover that professional website projects require lead time. Consequently, they either launch something unfinished or postpone into the new year, missing their intended business window.
The Q4 rush cycle explained
Here’s what actually happens in the typical Q4 scenario.
July and August, teams are heads-down on existing priorities. A few people think, “We should probably refresh the website this year,” but it stays vague. More importantly, nothing moves because budget cycles haven’t landed yet.
September arrives. Budget is confirmed. Someone decides this is the year. They email three or four agencies requesting proposals. As a result, agencies are now estimating work for Q4 delivery. For most professional agencies, October is already fairly booked. November is completely booked. December is reserved for final testing and launch support on projects that started in summer.
The agencies respond with realistic timelines. Eight to twelve weeks minimum for a standard website. This means October start gives you a January delivery date. September start gives you a November delivery date. No agency commits to a December 24th launch for a project starting in October because that’s eight weeks on a calendar that includes holidays, not eight working weeks.
Then someone decides the timeline is too long. Perhaps they ask, “What if we go with a template instead of custom design?” Speed doesn’t come free. More importantly, speed acquired through template solutions usually means you launch something that doesn’t quite fit your actual needs. As a result, post-launch refinements and feature additions pile up in Q1, which is exactly the opposite of what you wanted.
Real timeline breakdown for standard projects
A standard website project typically takes 8-12 weeks. Here’s what that actually means in practice.
Weeks 1-2 are discovery. Your agency learns about your business, your audience, your constraints, your previous site performance, and what success looks like. This can’t be rushed. More importantly, this is where decisions get made that affect everything downstream. If you’re vague about your constraints, discovery takes longer.
Weeks 3-5 are design. This includes sitemaps, user flows, wireframes, and visual design. Specifically, this is where you’re testing approaches and getting stakeholder alignment. If you have multiple decision-makers who disagree about direction, design takes longer.
Weeks 6-9 are development. This is where the site gets built. If you’ve been clear about integrations and constraints, this is straightforward. More importantly, if you discover halfway through that your legacy email system doesn’t connect the way everyone thought, this phase extends.
Weeks 10-11 are content migration, testing, and launch preparation. Content gets moved into the new system. Performance is optimised. Edge cases are found and fixed. As a result, having your content ready before week ten is crucial. If you’re still writing copy in week nine, testing suffers.
Week 12 is launch and launch support. This doesn’t mean the site goes live and then everyone goes home. Typically, the agency supports the launch and watches for issues in the first few days.
This timeline assumes you’re making decisions promptly and providing content when it’s needed. If stakeholder approvals take two weeks each, add two weeks. If content appears piecemeal throughout the project, testing gets squeezed.
Complex projects take 12-16+ weeks
When projects are more complex, timelines extend. This isn’t agency incompetence. This is reality.
The Fulcrum project demonstrates what happens with genuine technical complexity. They operate across multiple jurisdictions with different regulatory requirements. A single centralised website architecture doesn’t work when you’re managing distinct compliance frameworks across different markets. Consequently, we built custom functionality to handle jurisdiction-specific requirements whilst maintaining a coherent user experience.
This kind of complexity requires careful coordination across workstreams. Design and development can run in parallel in some areas, but in others they’re sequential. When multiple systems need integrating, discovery takes longer because you’re understanding how those systems actually work, not just what people think they do.
More importantly, timeline complexity comes from coordination complexity, not just technical difficulty. A simple custom site with one integrating system takes less time than a site with five integrations, even if each integration is individually simple.
The problem with “it’s only a website” thinking
Someone always says, “It’s only a website. How hard can it be?” This usually comes from someone who hasn’t thought carefully about what a website actually is.
Your website is a communication system, a customer acquisition system, a sales tool, and a customer support resource. It’s probably integrated with your CRM, your email system, your analytics, your form providers, and potentially your e-commerce platform. Each integration adds complexity and timeline.
Specifically, if you treat the website project as a design refresh rather than a system redesign, you’ll miss opportunities and create problems. A new design layered on legacy architecture often reveals that the architecture doesn’t support what you actually need.
What happens when you compress timelines
Every phase of a website project involves a speed-quality-scope tradeoff. Speed requires giving up either quality or scope.
Compress discovery, and you miss constraints that become expensive when they surface midway through development. More importantly, compressed discovery usually means inadequate content planning, which becomes the hidden killer later.
Compress design, and you end up with less refined direction. More importantly, designers can’t think carefully about user experience. Specifically, this usually means post-launch revisions that cost more than getting design right initially.
Compress development, and you introduce technical debt. The site works, but it’s fragile. Changes in future months require disproportionate effort because corners were cut. As a result, your post-launch iteration velocity slows.
Compress testing, and you launch bugs. Some are cosmetic. Others affect conversion. This is where compressed timelines usually show their cost.
Content as the hidden timeline killer
Most organisations underestimate how much content work a website project involves.
A 50-page website might sound manageable until you realise each page needs: current copy to be audited, new copy to be written, images to be sourced or created, metadata to be structured, and compliance review if you’re in a regulated industry. As a result, a 50-page migration isn’t a two-week task. It’s a two-month task when done properly.
The Secomak project illustrates this. They had 100+ product pages, each with technical specifications, compliance documentation, regional variations, and imagery requirements. Content migration wasn’t a afterthought; it was the project’s largest component. Understanding this upfront meant the budget and timeline accounted for it. Specifically, they hired internal resources to do content work in parallel with design and development, which compressed the overall timeline.
If you’re starting a website project in October with 100 pages that need migrating, and content work doesn’t start until week six, you’re launching in January at best. If content work starts in week one, you launch in November.
The October start reality: specific maths
Let’s be concrete. You’re starting October 1st. You want to launch before Christmas.
October 1st to December 24th is 12 weeks. That’s a standard project timeline if everything moves smoothly. More importantly, November and December have holidays that reduce working weeks. The US has Thanksgiving. The UK has nothing significant in November but Christmas impacts December heavily. As a result, you actually have about 10-11 effective weeks in that window.
Most agencies aren’t committing to December 24th launches for October starts because they know half of week twelve will be interrupted by closures. This means you’re looking at January 7th realistically, which is after the Christmas pause. This defeats the purpose of a Q4 launch.
What if you start October 15th instead? You’ve just lost two weeks. Now you’re looking at January 21st if you’re lucky. Specifically, you’ve missed the window you wanted.
Compare this to a September start. September 1st to November 24th is 12 weeks, and very few holidays interrupt those weeks. You can launch in late November and have your new site live for the year-end period. More importantly, if issues arise in the first week of December, you have time to address them before year-end.
Smart planning: August preparation, September kickoff
The timeline that actually works looks like this.
August is your planning phase. You create a brief. You identify and vet potential agencies. You have planning conversations. You get stakeholder alignment on what success looks like. Specifically, you’re not starting any build work in August. You’re preparing for it.
September is when you kick off the project. You’ve already done the thinking. You’re ready to start discovery. More importantly, you’ve got 16 weeks until Christmas, and you’ve already used the summer months productively.
Discovery happens in early September. Content work starts in mid-September in parallel with design. Development starts in October. Testing and launch happen in November.
This timeline is comfortable. It doesn’t require heroics. More importantly, it gives you buffer for the unexpected issues that always arise.
Case studies: realistic scoping
Validis started planning in May and kicked off in July. They took two months for discovery and planning because their brand situation was complex. More importantly, they used that time well. When design started in September, they knew exactly what they were designing for. The 14-week timeline from kickoff to launch meant they delivered in November, not January. The results were stark: 65% increase in click-through rate, 55% increase in average session duration.
FlexFactor operated on a tighter timeline. They raised Series A funding and needed to scale their website quickly. The discovery phase was compressed because their needs were clear. They started in August with a compressed 10-week timeline. More importantly, they delivered in late October. Their metrics showed the value of realistic planning: 63% increase in clicks, 58% increase in impressions. They didn’t achieve these numbers through speed. They achieved them through clarity.
When agencies say “fully booked”
If you’re contacting agencies in October asking for Q4 delivery and they say they’re fully booked, this isn’t frustration. It’s honesty.
The agencies who say yes to October projects with December deadlines are either overcommitting (which means quality suffers) or padding their timeline estimates (which means you launch in January anyway). More importantly, the agencies who were actually available for October starts are usually available because they’re less experienced or less selective.
The availability paradox means the best agencies are booked furthest in advance. They fill their capacity with well-planned projects from organisations that understood timeline requirements. If you’re starting in October, you’re competing for whoever has gaps. Specifically, gaps often exist because those project slots are lower quality work.
What to do if you’re reading this in late summer
If you’re reading this now and realising you wanted a Q4 website launch, you’re not out of time. You are out of time for a comprehensive redesign with a professional agency. More importantly, you have options.
Option one: brief an agency now for a September start with a November launch. This is feasible if your scope is modest and you’re ruthless about what you’re including.
Option two: postpone to a January start and do proper planning now. More importantly, use the rest of the year to validate assumptions and prepare content.
Option three: do a smaller scope project now (homepage refresh, landing page, etc.) and plan a comprehensive redesign for Q1 or Q2.
Specifically, don’t choose option four: panic and launch something half-finished. That costs more in post-launch fixes than proper planning would have.
What if you’re reading this in September or October
If you’re starting now, you’ve already missed the comfortable window. You’re looking at a January or February launch date for standard work. More importantly, this isn’t failure. This is reality.
Communicate this to your stakeholders now rather than discovering it in November when the team is exhausted and cutting corners. A January launch isn’t ideal, but a January launch with proper discovery, design, and testing is better than a December launch that’s half-finished.
More importantly, use November to get ahead on content and testing. Specifically, if you start preparation work in parallel, you can get a January launch that doesn’t require extending timelines further.
Why we write this article every year
The timeline maths doesn’t change. Eight to twelve weeks for standard websites. Twelve to sixteen weeks for complex work. Add holidays and decision delays, and Q4 launches require September starts.
Every year, some organisations get this right. They start planning in summer. They kick off in September. They launch in November with a functional, well-tested site.
Every year, other organisations discover in October that timelines aren’t flexible. More importantly, they make hurried decisions that compromise the work.
The variable isn’t the timeline. It’s whether you’re planning forward or reacting. Specifically, the choice is usually made in August when the year still feels long.
Read the related articles for more context: How to Plan Your Website Project Without Wasting Time and Decision-Making Frameworks for Digital Projects.
Case study details: Validis, FlexFactor, Fulcrum, Horizon Global Partners, and Secomak.
Sector-specific service pages: financial services, technology, manufacturing, start-ups. The 4D Framework covers our underlying process.
Frequently asked questions
Can a website really not be delivered in less than eight weeks?
Standard websites with proper discovery, design, development, and testing take 8-12 weeks. Shorter timelines usually mean cutting one or more of those phases, which trades off quality or completeness. A landing page or template site can be faster. A comprehensive website addressing a complex business need requires the full timeline.
What if we need it faster than the standard timeline allows?
Faster delivery requires reducing scope. Instead of a full website redesign, can you do a homepage refresh or a few key landing pages? Can you launch with core features and add secondary features in following months? More importantly, be specific about what matters most and what can wait.
Does timeline length affect the final quality?
Adequate timeline allows for proper discovery, design thinking, testing, and iteration. Compressed timelines usually mean skipping discovery conversations or testing phases. As a result, you launch faster but with higher risk of issues. More importantly, the relationship is usually indirect: poor planning matters more than timeline alone.
When should we ideally start planning a website refresh?
For a comfortable Q4 launch, you should start planning in July and kick off in September. For a summer launch, you should plan in April and kick off in May. Specifically, give yourself two months for planning before you need to start the work. This prevents the rushed October conversations where no agency has capacity.
How do we avoid scope creep when timelines are tight?
Document your initial scope clearly before you start. Specifically, treat every new feature request as a change request that either extends the timeline or removes something else. More importantly, have a formal approval process for scope changes that involves your stakeholder and your agency. Without this, scope creep is inevitable and timelines always slip.
