How long does a website take? The stages that shape the schedule

There is no duration that applies to every website. A campaign page with approved copy, a multilingual business site and a store linked to accounting systems have different dependencies and testing needs.

Ask for a schedule built around tangible deliverables. Each phase should have an owner, required inputs, an expected outcome and a clear feedback rule.

Discovery defines audiences, objectives, journeys, languages, features, legal constraints and external systems. It also identifies what will not be part of the first release.

Faster development cannot repair an incomplete brief. Deferred decisions often return during integration, when they affect several pages or components at once.

Copy, translations, photography, legal information and product data need an owner and status. Use a shared inventory to distinguish draft, approval, translation and integration.

Design with representative content as early as possible. Placeholder text does not expose real needs such as a long heading, table, allergen detail, variant, error message or call to action.

Start with structure and priority journeys, then approve a few templates before producing every page. This makes disagreements visible before they spread.

Plan third-party integrations separately. Missing access, incomplete documentation or an unavailable test environment can block a feature even when its interface is ready.

Test the agreed browsers and devices, keyboard use, forms, languages, links, metadata, redirects, performance and error cases. Use real content and, for a store, test transactions.

Centralise feedback, classify it by severity and avoid late visual preferences that reopen approved work. A blocking defect is not the same as a preference.

A brochure site of five to eight pages, with content already prepared and a single decision-maker, is generally delivered in three to five weeks: one week of discovery and architecture, one to two weeks of design and development, one week of integration and testing, a few days for feedback and launch. Calendar time is mostly consumed by approvals, not by production.

A multilingual site of fifteen to twenty-five pages with one external integration — appointment booking, newsletter, catalogue — takes more like six to ten weeks. Translation adds a full proofreading cycle per language, and each integration adds a test phase that depends on a third party.

An online shop with around a hundred products, variants, several delivery methods and an invoicing connection is planned over two to four months. Catalogue preparation by the merchant is almost always the critical path: photographs, descriptions, weights, dimensions and codes for every product must exist before the checkout can be tested with real data.

At discovery: access to the domain name and current hosting, the logo in a vector format, brand guidelines if they exist, statistics from the existing site and the list of people who approve. A domain whose registrar nobody remembers can block a launch for weeks.

• Before design: the copy for the main pages, even if imperfect.
• A mock-up designed on real text is right first time; a mock-up designed on placeholder text is redone at integration.
• Photographs and video follow the same rule: it is better to learn early that a photo shoot is needed.

Before testing: the validated legal notice, terms and conditions for a shop, final contact details, prices and translations proofread by a native speaker. Each of these delivered late pushes the launch back by the same amount, whatever the supplier’s speed.

In most projects, production accounts for less than half the calendar time. The rest is waiting: feedback promised for Tuesday that arrives the following Friday, three contradictory opinions on a colour, an approved mock-up reopened after being shown to a third party.

• Two rules cut that time dramatically.
• First: a single decision-maker, who consults whoever they like but decides alone and in writing.
• Second: a feedback deadline agreed in advance, for example three working days, after which the stage counts as approved.

Group feedback as well. A complete, prioritised list sent once is handled in one session; ten messages scattered over a week are handled in ten interruptions and produce omissions. The supplier should provide a simple tool or template for this, and the client should use it.

Transferring a domain name between two registrars can take from a few hours to several days, and longer if the old registrar imposes an unlocking procedure. DNS propagation after a hosting change is usually quick but can reach forty-eight hours for some visitors. Neither speeds up by insisting.

• Opening an account with a payment provider involves identity and business verification that takes from a few days to several weeks.
• A shop can be fully built and tested in sandbox mode, but it cannot take money until the account is approved.
• Start that process at discovery.

Integrations with business software — till, accounting, calendar — depend on access, documentation and sometimes a contact at the vendor. Expect one of them to slip, and keep a launch plan that works without it: the site goes live on the planned date, the integration follows.

A live site works: it receives enquiries, gets crawled by search engines, lets you measure what visitors look for and correct course. A perfect site in a folder does none of that. Every week of delay to add a team page or polish an animation is a week without the main thing.

So define a first release that contains what answers customers’ questions and nothing more, launch it, then add the rest in small planned deliveries. This split also makes the schedule more honest: the first date is short and achievable, the following ones adjust to what the site learns.

This method is no licence to neglect what is hard to fix later: URL structure, basic accessibility, performance, redirects in the case of a redesign. These foundations belong in the first release because they cost little at the start and a great deal to correct afterwards.

Map dependencies first, then add approval dates. Include contingency proportionate to the remaining unknowns and agree how scope changes will be handled.

The final schedule must be specific to the project and confirmed after discovery. If an external deadline is fixed, reduce the first release explicitly instead of promising the same scope in less time.