All Digital

How long does a professional website take?

The build is rarely the bottleneck. Decisions, content and review turnaround are - and all three are on the client side.

Written by All DigitalPublished Updated

Short answer

The schedule is set by four things: how many distinct templates need designing, how much custom logic sits behind them, whether final content exists, and how fast feedback comes back. Of those, the last two are usually the client's to control and are the most common reason projects run late. A project where content is ready and one person can approve decisions finishes in a fraction of the calendar time of an identical project where neither is true.

What the stages actually consist of

Understanding what happens in each stage makes it obvious where time goes, and which parts you can influence.

  • Discovery. Goals, audience, content inventory, integrations, constraints. Short in calendar time, but skipping it moves the cost to a later stage where it is far more expensive.
  • Design. The visual system and each distinct template, prototyped and reviewed. This stage is dominated by review cycles, not by drawing.
  • Build. Templates coded, logic implemented, integrations connected, shipped in increments to a staging URL. The most predictable stage, because it is the one with the fewest unknowns left.
  • Launch. Performance, accessibility and technical SEO passes, redirects if a site is being replaced, deployment and handover. Short unless a redirect map is involved.
  • Post-launch. Fixes, adjustments and monitoring. Always budget for this. Every project has a short tail.

The three things that cause almost every overrun

In our experience these account for nearly all lost time, and none of them are technical.

  • Content that does not exist. Design starts with placeholder text, the real copy arrives at half or double the length, and the layout is redone. This is the single largest avoidable delay in web projects.
  • Unclear decision-making. When four people must agree and none of them can decide, every review round takes a week instead of a day. Naming one person who can approve is the cheapest schedule improvement available.
  • Requirements that were not settled. Not scope changes - genuine ambiguity that was carried forward because it seemed small. Business rules that are not decided at design time surface during build, when changing them costs the most.

What genuinely shortens a project

These work. Adding developers to a late project does not.

  • Have final copy written, or accept that the design will be built to fit approximate lengths and not re-done when copy arrives
  • Name one person who can approve design and content decisions
  • Agree a review turnaround up front - two working days is realistic, same-day is not
  • Get access to third-party accounts early: payments, analytics, domain, hosting, any existing CMS
  • Cut scope rather than quality when a deadline is fixed, and decide together which parts move to a second phase
  • Launch the core site and add the secondary sections afterwards, if there is a hard date

Why we do not publish a delivery time

For the same reason we do not publish prices: the range is so wide that any single figure would be misleading. A one-page site with copy ready and a multi-tenant platform with scheduling and invoicing are not the same kind of project and do not share a schedule.

What you should expect instead is a written stage plan with the dependencies named - including the ones that are yours - before any commitment. A studio that gives you a delivery date before asking what the site has to do has not estimated anything.

A note on fixed deadlines

Hard dates are legitimate. Trade shows, seasons and campaigns are real. What does not work is treating a fixed date as a reason to compress every stage equally, because the stages that get compressed in practice are testing and launch checks - the ones that protect you.

If the date is immovable, the honest response is to cut scope. Decide together what launches and what follows, and ship a smaller site properly rather than a larger one that is not ready.

Frequently asked questions

A single well-made page with content ready, sometimes. A full site with several templates, no. What can be done quickly is launching a deliberately small first version and extending it, which is usually a better outcome than a rushed larger one.

Because design is where the decisions happen, and decisions involve people. The drawing is not the slow part; agreeing what should be drawn is.

Say so at the start rather than promising it for next week. We can design against realistic content structures and lengths, and agree which pages launch first. The costly path is designing around placeholders and discovering the real copy does not fit.

Rarely, and usually the opposite. Most of the delay is in decisions and content, and adding developers does not help with either. It adds coordination cost to the one stage that was already running predictably.

Want this applied to your project?

Send a short brief and we will give you a specific answer rather than a general one.

Start a project