How long does it take to build a website?

What does the timeline look like by type of build?

Scope sets the calendar more than the platform does, so the honest answer is a range per shape of build. The table below is how I scope them; the four shapes I build most often each have their own post with the week-by-week detail.

What happens in each week?

A six-week custom WordPress build runs through four phases, and the client's part of each one sits on the calendar next to mine.

Why is the code the fastest part?

Because the code has one author and the rest of the project has several. Copy needs a writer and an approver. Photography needs a shoot or a licence. Product data needs someone who knows the catalog. Every one of those hands off to a person whose calendar is not the project's.

The last headless rebuild I shipped shows the shape of it. From the first commit to the day the new site replaced the old one took nine weeks, and 40% of the commits landed in the final two. Almost none of those were features: three rounds of requested edits, photo swaps, metadata audits, a content-security exception for a tag manager, and deploy retries. That is what a launch fortnight looks like on a build that was on schedule.

Migration is the third long pole. An old site has URLs that rank, content that half-fits the new templates, and a redirect map that has to be right on the first request. It is its own workstream, and retiring a page without losing its search value is a discipline rather than a footnote.

What makes a website take longer than quoted?

Six things, in the order I see them:

• Content arriving late, or changing after the templates that hold it are built.
• A second round of design after the build has started. Revisions in a design tool cost hours; the same revisions in built templates cost days.
• Approval by committee. Each extra approver adds a round, and rounds are measured in weeks.
• Integrations with systems nobody has documentation for.
• An old site whose URLs, content and media all have to be mapped before anything can be cut over.
• Waiting on access: the domain registrar, the hosting account, analytics, brand assets.

None of these is a surprise inside the project. The trick is naming them in discovery, with a date and an owner, so they are on the plan instead of in the way.

How do you make it go faster?

• Put the content in a shared document before kickoff. Even rough copy with headings beats a blank template.
• Appoint one decision-maker with a standing weekly review slot. Speed of decision is the biggest lever a client controls.
• Cut pages, not quality. Five finished pages launch; twelve half-finished ones do not.
• Accept a tuned theme when the design does not need to be bespoke. A custom design system is a real cost in weeks.
• Decide integrations in discovery and get the credentials the same week.

That is the shape of how I scope and schedule a website build: a milestone plan before work starts, with your deadlines on it next to mine.

Can a website really be built in a week?

Yes, with a template and content you already have, and that is sometimes the right answer. A template site gives you a URL, a contact form and a design someone else made; what you trade is performance you did not tune, a structure you did not choose, and edits that fight the template. If the deadline is genuinely a week, a template is the right tool and I will say so. The two-week launch site is the shortest build I put my name on, because the theme, the form delivery, the analytics and the performance pass are verified rather than assumed.

Questions