How long a website project actually takes

Every website quote carries a timeline, and most of them are missed. Not by a little — four weeks routinely becomes eleven. This is common enough that both sides have learned to expect it and neither enjoys discussing it.

The causes are predictable. Almost none of them are technical.

Honest ranges

A small site, content supplied — three to five pages, text and images ready. Two to three weeks.

A small site, content written for you. Four to seven weeks. The writing is not the slow part; agreeing what the business is trying to say is.

A designed site with a blog and forms, eight to twelve pages. Six to ten weeks.

Anything with integrations — payments, CRM, booking, an existing system. Add two to six weeks per integration and mean it. Integrations are where estimates die, because you cannot see the problems until you are inside someone else's API.

These assume one decision-maker who responds within a couple of days. That assumption is where most of them break.

The two things that cause nearly every delay

Content. This is the first cause by a distance. A project reaches the point where real text and real images are needed, and they do not exist. Everyone knew they would be needed. Nobody had time, because writing about your own business is genuinely hard and always loses to whatever is urgent.

A site with placeholder text cannot be finished, reviewed or launched. The project stops, and the stop is invisible — it looks like the developer is slow.

Feedback loops. A round of review that takes eight days instead of one adds a week, and there are usually four or five rounds. That is a month, from nobody doing anything wrong.

It gets worse when feedback arrives from several people separately, in conflict. Two rounds become six, and each is a fortnight.

Most overruns are not weeks of work. They are weeks of waiting, on both sides, that nobody scheduled.

What actually shortens a project

Write the content first. Before design, before anything. It is the single biggest lever and almost nobody pulls it. A project that starts with real words moves at roughly twice the speed.

One decision-maker. Others can advise. One person decides, consolidates the feedback, and speaks with one voice.

Book the review slots up front. Put the three or four feedback dates in the calendar at kickoff, before anyone knows what they will be reviewing. Unbooked reviews slip indefinitely.

Agree what launch means. Write down what must be true to go live. Without that line, projects acquire small additions forever and never quite finish.

The small thing that moves launch day

Most of a project's last week goes on something nobody listed: access. The domain is registered with a freelancer who left, or in an email account nobody can open. The DNS is held by a hosting company that takes two days to answer. The business email runs on the same domain, and changing the records without care stops it working for an afternoon.

None of this is hard. All of it is slow when it is first looked at on launch day. Ask in week one, not week ten: who can log in to the domain registrar, where the DNS is managed, which services send email from the domain, and whether you have the login for each. If the answer to any of them is "I would have to find out", find out now. It takes an hour and it removes the one delay that neither side can speed up.

Do the same for any third-party account the site depends on, such as the payment gateway, the analytics and the form notification inbox. Payment gateways in particular can take days to approve a business, and that clock does not start until you apply.

When a faster date is the wrong ask

Sometimes the date is real: a launch event, a campaign, a season. Then the honest move is to cut scope, not to compress the schedule. Launch the five pages that matter and put the rest in a second phase with its own date.

Squeezing the same scope into fewer weeks does not work. The waiting does not shrink, so the build does, and testing goes first. If a studio promises that without asking what you will drop, be careful.

And if nothing is tied to the date, a slower start with the content ready beats a fast start that stalls at week three. We would rather begin a fortnight later than watch a project sit on placeholder text.

What a realistic plan looks like

Not a Gantt chart. Four or five checkpoints, each with a date and a named owner — including your side. Content due. Design agreed. Build review. Launch.

If a plan has no dates against your own obligations, it is not a plan. It is a quote with weeks written on it. The cost calculator shows the usual timeline next to each price band, which is a fair check on any plan you are handed.

The uncomfortable part

If a project has slipped badly before, look at where the waiting happened. In our experience the answer is usually uncomfortable and usually the same: content that arrived late, and feedback that took longer than anyone expected.

That is fixable, and it is fixable before the project starts rather than during it. A clear brief helps more than anything else — it is the difference between a project that ends and one that just stops.