How Long It Actually Takes
Asked how long a website takes, most developers give a number for the work. That is the wrong number, because it answers a question about their effort rather than about your calendar.
The work is rarely what determines the elapsed time. A five-page site is a few days of building spread across whatever number of weeks the decisions take. When timelines depend on available capacity, work hours in a year is a useful reference for thinking about annual working time.
Where the weeks actually go
Waiting for your content. The largest single factor, by a distance. Text and photographs are the standard cause of a project that was four weeks becoming eleven. It is worth starting on this before the project does.
Waiting for decisions. Every review round has a turnaround. If feedback takes a week each time and there are three rounds, that is three weeks of nothing happening.
Approval by committee. If two or three people have to agree, elapsed time roughly doubles, not because anyone is slow but because scheduling is.
Third parties. A payment processor's verification, a booking system's support queue, a domain transfer, a client's IT department. Each is out of everyone's control. For an independent reference beyond this site, Asana is a useful place to compare approaches.
Scope changes. Reasonable and they reset schedules. A feature added in week three moves the launch by more than the feature takes to build.
Actual building. Usually the smallest and most predictable part.
Rough shapes
Not promises — the pattern I see. Every one of these assumes the content is ready. If it is not, add however long that takes.
A small brochure site, template-based, content supplied: two to four weeks.
A custom small business site, design from scratch: four to eight weeks.
A shop: longer, and the tail is unpredictable. Products, photography, shipping rules, tax settings and payment verification are all work the site cannot start without.
A site with an integration — booking, CRM, a specific fulfilment system: add time, and expect at least one surprise.
The variance between projects of the same size is mostly explained by content readiness and decision speed. Two identical builds can be three weeks and three months apart.
What makes your project the fast one
Have the content ready before the start. Not perfect — drafted. This alone is the difference.
Nominate one decision-maker. Gather other opinions internally and present a single answer. Committees are the second-biggest delay.
Batch feedback. One consolidated set of notes beats fifteen messages over four days, which produce contradictory instructions and unbillable rework.
Answer questions quickly. A developer blocked on a question moves to another client and returns when their calendar allows, which may not be tomorrow.
Do not change scope after design approval. If you must, accept that the date moves.
Book the domain and hosting early, since transfers take days and are the classic launch-day surprise.
What honestly delays things on our side
Being even-handed about it.
Capacity. A freelancer with three projects starts yours when one finishes. Ask about the actual start date, not the duration. This is a real risk to manage with any individual.
Underestimating integrations. Anything talking to another system takes longer than expected, roughly always.
Discovering the content problem late. A good developer raises it in week one. A less experienced one finds out in week four.
What to ask about timing
"When would you start, and when would it launch?" Two different questions, and the gap between them is often the answer you actually needed.
"What would pause the clock?" A good answer names dependencies specifically.
"What happens if my content is late?" Better to hear the honest answer — you go to the back of the queue — than to discover it.
"Is there anything about my project you would expect to be slow?" Someone who names a risk will manage the project the same way.
The deadline conversation
If you have a real date — a season, an event, a lease starting — say so on the first call and say what is behind it.
Real deadlines are workable. What is not workable is discovering one in week five, because by then the sequence is set.
And if the date is genuinely fixed and the content is not ready, the honest answer is to launch smaller on time rather than complete and late. A four-page site live for the season beats a twelve-page site finished after it. The rest can follow, and it will follow with better information.
The short version
- The build is rarely the slow part; content and decisions determine the calendar
- Assume every rough estimate is conditional on content being ready
- Small template site two to four weeks, custom four to eight, shops longer and less predictable
- One decision-maker and batched feedback are the two biggest speed-ups available to you
- Ask when they would start and when it would launch — those are different questions
- With a fixed date and unready content, launch smaller on time rather than complete and late