How Long Does It Take to Build a Website? The Four Stalls That Set Your Calendar

Four neighbouring questions are assumed here rather than re-argued. What the work costs is in how much a website costs for a small business, and there are no prices below. Whether you should rebuild at all is a separate diagnosis, worked through in signs you need a new website. Who should build it is in how to choose a web design agency. And how long results take after the site is live — a completely different clock — is in how long SEO takes to work.

This piece is about one number: the days between saying yes and going live. Every owner asks for it, every proposal contains it, and the two almost never match. Understanding why is worth real money, because the gap is not caused by the thing everyone blames.

The Ranges, Before the Caveats

A brochure-style site of five to fifteen pages — services, about, contact, a handful of proof pages — is normally two to six weeks from kickoff to launch. A site with real functionality attached, such as booking, memberships, a quoting tool, or an integration into software your business already runs, is normally eight to sixteen weeks. E-commerce sits at the top of that band, because the catalogue, the tax and shipping rules, and the payment setup are each their own project wearing a costume.

Those are well-run numbers, not lucky ones. If your experience of website projects is that they take four months and end in exhaustion, you are not remembering wrong and nobody lied to you. The estimate measured working hours. Your calendar measured elapsed days. Those only agree when the project is never waiting on anything, and the typical small-business project spends more days waiting than being worked on.

Where the Calendar Actually Goes

Sit with any stalled project and the same four causes appear, in roughly the same order, in nearly every one. None of them is technical. All four are worth more elapsed time than the construction they interrupt, because each one costs a day or two of actual work and a week or more of sitting still.

Stall One: A Decision Nobody in the Room Can Make

The project reaches a fork — which services lead, whether to show pricing, what the primary action on the page is, whether the old brand name stays. Whoever is on the call cannot decide it alone. So it goes to the owner, who is on a job site, and it waits.

What makes this expensive is not the decision. It is that the fork usually sits at the front of the work, so everything downstream is blocked behind it, and a project can lose two weeks to a question that takes four minutes to answer once the right person hears it. The fix is unglamorous and it works: one named decision-maker with real authority, identified before kickoff, and a standing short slot each week where anything blocked gets resolved. Businesses that do this finish near their estimate almost regardless of what the site involves.

Stall Two: The Content Exists Only in One Person’s Head

Nearly every business assumes its content already exists, because it exists on the current website. Then somebody reads the current website and finds three services you dropped, two you added and never listed, a team page with people who left, and pricing language you have not honoured since 2023.

So the real content task is not writing. It is extraction: getting what the business actually does today out of the owner’s head and onto a page. That is a genuine constraint, because the person who holds it is also the person running the business, and it is the reason so many projects go quiet at the halfway mark with a design approved and nothing to put in it.

Photography is the same problem in a different medium and is worse, because it needs a day nobody has scheduled. Waiting on a shoot has ended more project timelines than any technical issue. The two ways through are to decide early that licensed stock is acceptable for the launch and to plan real photography as a post-launch swap, or to book the shoot in week one rather than discovering the need in week five.

Stall Three: Nobody Can Find the Logins

This one is invisible until launch week, and then it is the whole story. Publishing a site requires control of the domain. Preserving your history requires access to analytics and your Google Business Profile. Keeping email working through a hosting change requires knowing how mail is currently routed. On a rebuild, none of that is optional.

And in a large share of small businesses, at least one of those accounts is held by a person who is no longer involved — a previous developer, a former employee, a relative who set it up as a favour in 2016. Recovering an account from an unresponsive holder is a process measured in days at best and weeks when it needs a verification step, and it cannot be started early if nobody checked. Which of these you actually control is the subject of do I own my website, and the fifteen minutes it takes to run those login attempts in week one is the highest-return quarter hour in the entire project.

Stall Four: The Review Round With Too Many Reviewers

A draft goes out for feedback. It goes to the owner, the office manager, the owner’s spouse, and a friend who once worked in marketing. Four sets of comments come back over eleven days, two of them contradict each other, and now somebody has to referee taste.

Review rounds are necessary and this is not an argument against feedback. It is an argument about arithmetic: elapsed review time scales with the number of reviewers, while the quality of the outcome does not. Two rounds with two reviewers and a deadline consistently produces a better site sooner than five rounds with five reviewers and no deadline. Agree the number of rounds and the turnaround window before the first draft, and treat a missed window as a decision to accept the draft.

What Genuinely Takes the Developer Time

None of this means the build is trivial. It means the build is predictable, which is a different thing. The parts that reliably consume developer days are structure, functionality, integration and migration — deciding what pages exist and how they relate to each other, anything involving forms, bookings, payments or logins, connecting to software you already run, and on a rebuild the page-by-page audit and redirect mapping that keeps existing rankings alive.

Two more items belong on the timeline and are routinely left off. Testing across real devices and browsers is not a rounding error, and accessibility and performance work is real engineering rather than a checkbox at the end. If a proposal shows zero days between final approval and go-live, the schedule is missing something, and you will meet it after launch instead.

When the Build Compresses, the Waiting Becomes the Whole Project

Here is the part that has genuinely changed, and the part most timeline advice has not caught up with. AI-assisted construction has taken large amounts of production time out of the middle of these projects. We build with Claude Code, and the construction phase for a straightforward site is now days rather than weeks.

The consequence is counterintuitive and worth planning around: when the developer stops being the bottleneck, everything else becomes visible. A five-day build with three weeks of waiting bolted to it is still a four-week project, and the waiting is now the overwhelming majority of the calendar rather than a background irritation. Which is exactly why we ask for the decision-maker, the content, and the account access up front instead of collecting them while building. The compression is only worth something if the front of the project moves too. That is the operating model behind our AI website building work, and it is also why the SEO and answer engine optimization layers get specified during the build rather than sold as a separate project six months later.

A Realistic Schedule for a Well-Run Small-Business Build

Week one is discovery and access: what the business sells today, who decides, what proof exists, and every login verified rather than assumed. Week two is structure and content — the page map agreed and the copy drafted from the discovery material instead of from the old site. Week three is construction and the first review round, with a deadline attached. Week four is the second review, testing on real devices, redirect mapping if this is a rebuild, and launch.

Four weeks is achievable and it is not a promise. It assumes one decision-maker, content decided rather than discovered, accounts in hand, and reviews returned inside their windows. Miss two of those four and the same project is nine weeks, with the additional five spent entirely on waiting.

Launch Day Is Not the Finish Line

The last timeline mistake is treating go-live as the end. A new site is normally crawled within days, but ranking for anything competitive is a months-long process and belongs on a separate calendar, which is the whole subject of the SEO timeline post linked at the top. Conversion behaviour needs a few weeks of real traffic before the numbers mean anything. And a rebuild deserves a deliberate watch on the pages that used to rank — if traffic moves in the wrong direction, the window to catch a redirect problem cheaply is short.

Budget for a working asset on launch day and a search asset later. Projects that expect both at once tend to conclude the build failed when what actually happened is that the second clock had barely started.