InsightsWorking together
How long a website project actually takes
Every website quote has a timeline and almost none survive contact. The reasons are predictable, and mostly not technical.
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.
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 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.
- timelines
- websites
- process
