How Long Should a Small Business Website Take to Build?

Ask around and the typical answer for a five-to-eight page local business site is eight to twelve weeks. Ask why, and the answers get vague: discovery, wireframes, revision rounds, QA, staging.

Those are real activities. They are not twelve weeks of activity. It is worth separating the time a project takes from the work a project contains, because they have almost nothing to do with each other.

Where the weeks actually go

Break a conventional timeline down and the pattern is consistent:

1. 01Kickoff and discovery: one meeting, then a week of nothing while a document is written.
2. 02Content collection: the longest phase and almost always the client's bottleneck — because they were handed a blank spreadsheet with no guidance.
3. 03Wireframes: grey boxes, sent for approval, waiting days for a reply on something nobody can meaningfully judge.
4. 04Design mockups: static images of pages, another approval cycle, another wait.
5. 05Revisions: two or three rounds, each with days of dead time between them.
6. 06Build: the actual production. For a site like this, days.
7. 07Review and launch: final checks, then waiting for a decision on going live.

Add up the hours of genuine work in a typical twelve-week small business project and you land somewhere near a working week. The rest is queueing.

Why the queueing exists

Some of it is honest capacity management. An agency running eight projects has to slot yours between others, and gaps in your timeline are someone else's build week. That is legitimate, but it is their constraint being billed as your process.

Some of it is the approval theatre. Wireframes and static mockups exist largely to create documented sign-off points. They protect the agency from scope disputes. They rarely help the client, because almost nobody can accurately imagine a real, moving, interactive website from a flat picture of one.

And some of it is that duration signals value. A site delivered in two days for a serious fee feels suspicious in a way that the same site delivered in ten weeks does not. That is a real market dynamic, and it is one of the least honest reasons anything takes as long as it does.

The cost of a long timeline is not just the wait

Slow projects degrade in specific, predictable ways:

• Momentum dies. The energy you had at kickoff is gone by week seven, and decisions that took minutes now take a fortnight.
• Scope drifts. Long timelines invite additions, and every addition extends the timeline that invited it.
• The business changes underneath the project — new services, a price change, a staff change — and the site launches slightly out of date.
• You are running your old site, or no site, for three months. Whatever the new one was worth, you did not get it during that window.

What actually justifies more time

Not everything can or should be fast, and pretending otherwise is its own dishonesty. Legitimate reasons for a longer schedule:

• Custom functionality — real booking logic tied to your systems, payments, inventory, integrations with software you already run.
• Large content migrations, where hundreds of existing pages need mapping and redirecting properly.
• Photography, which depends on scheduling, weather, and people being available.
• Genuine brand work — naming, identity, a full visual system — which is a different project wearing the same coat.
• Multiple stakeholders who must all agree. This is a real constraint and it is yours, not the builder's.

What does not justify it: writing five pages of copy, choosing colours, or building a straightforward marketing site for a local business.

The way we run it

We compress the timeline by collapsing the queue, not by cutting the work. The mechanism is simple: you see a finished concept of your site on the first call. Not a wireframe, not a mood board — a real page, in a browser, with your business on it.

That changes the conversation immediately. You are no longer approving an abstraction and hoping. You are reacting to something concrete, which is the only kind of feedback that is reliably useful. Most of the revision rounds in a conventional process exist to slowly converge on what a concrete first draft establishes in twenty minutes.

From there a site can be live in as little as 24 hours. That number surprises people, and it is worth being precise about what makes it possible: the work was always days, the content questions get asked properly on the call instead of by spreadsheet, and there is nobody's queue to sit in.

It is also worth saying what it is not. It is not a template with your logo dropped in. It is not fewer decisions — it is the same decisions made in one focused sitting instead of eleven emails.

What to ask for

Whoever you hire, push on these:

1. 01See something real early. A working page beats any static mockup as a basis for a decision.
2. 02Get the timeline broken into work time and wait time. You are entitled to know which is which.
3. 03Ask what specifically is required from you, and when. Vagueness here is the number one cause of slipped projects.
4. 04Agree what happens if it slips. Not a penalty — just a stated expectation, which is enough to change behaviour.

Speed is not the goal in itself. But a timeline built around anything other than the actual work is time you are paying for and not receiving.