A website's launch date depends on the development scope, content readiness, approval speed and external services. A promise such as “a website in a month” is useful only if it explains what that month includes and when the clock starts.
As a client, you need a schedule with clear stages: when decisions are made, what your team must provide and which tasks could delay launch.
Here is how to assess a timeline, identify common delays and agree on the conditions before the project begins.
Five pages with finished copy and a repeated structure differ from five pages with custom workflows, translations and a non-standard booking system.
Project duration is affected by:
The initial amount of content matters too. Creating a product page template and adding a few examples is a different task from preparing and checking an entire catalogue.
A website development brief helps collect these requirements. Until they are defined, the timeline remains a preliminary estimate.
Clarify what the stated timeframe means: the team's working days, the project's elapsed calendar time or the period from development start to handover.
The calendar may also need to include:
For example, our commercial proposal for a custom multi-page website states 20 working days. This is the published proposal's reference timeframe for its defined scope. The starting point, approval schedule and effect of additional requirements must be agreed for your specific project.
Do not automatically assume that the website will be published exactly four calendar weeks after your first enquiry.
The team clarifies the pages, user journeys, content and constraints. The outcome is a clearly defined project scope.
If new sections are added or the booking process changes afterwards, the estimate for the affected tasks needs to be updated.
Copy, photographs and data can be collected alongside some of the planning work. Final page checks, however, require real content.
A temporary three-word heading does not show how a long service name will look on a phone. Missing prices or terms may change the structure of an entire section.
This stage confirms the interface's appearance and behaviour. Its duration depends on the number of designs and the feedback process.
Use our Figma design approval checklist to give the developer clear, agreed decisions.
The team implements pages, responsive layouts, forms and the agreed integrations. External systems may require active accounts, documentation and another specialist's involvement.
Check the feasibility of complex connections early. Otherwise, a service limitation may only become apparent after the interface has been approved.
The main user journeys need to be checked, feedback collected, issues fixed and the result checked again. The published version then needs to be reviewed on the main domain.
Allow time for this stage in the schedule. If development runs right up to an advertising campaign's start date, there may be no time left to fix the issues discovered.
Suppose a company is preparing a service website in one language. Copy and images are ready, one person is responsible for approval, and the integration uses a connection method that has already been checked.
The following schedule is an illustrative example, not a market benchmark or our agency package's delivery timeframe.
Now change one condition: the design is approved on day nine, but final copy arrives on day fourteen. Some work can continue, while certain pages have to wait or be reworked.
The launch delay depends on which tasks are blocked. You cannot simply add every day of waiting to the entire project if the team could work on other tasks.
The schedule should show the chain of tasks that directly determines the launch date. Delays in that chain deserve attention first.
A price changes after the page is built, photographs are replaced just before publication, or a translation is substantially longer than the original.
Set a delivery date for approved content. Assess later changes according to the pages and languages they affect.
One participant approves a design, while another requests conflicting changes. The provider spends time establishing which decision is final.
Appoint an owner and submit one agreed list of feedback for each version.
A new function may require changes to structure, design and integrations. Even a short request can affect several stages.
For each change, record its scope, cost, effect on the timeline and the decision: include it now or move it to the next version.
Access, the required subscription plan or account verification is missing. The provider cannot complete the user journey.
List these dependencies before the build begins and assign people to prepare them.
Problems with a form, payment or mobile menu are discovered immediately before launch.
Check completed workflows as they become available and leave time for a final review of the whole website.
If the date is fixed, agree on the minimum scope of the first version. For example, launch the main services and a working enquiry form, then add further case studies and a secondary section later.
Useful ways to speed up the work include:
Reduce scope by removing complete non-essential tasks. A working form, a usable mobile version and correct contact details remain part of a website's readiness for launch.
Before starting, agree:
Prepare a website acceptance and handover checklist as well. It helps establish what must be checked by the final stage.
A realistic timeline brings scope, responsibilities and the sequence of work together. It makes the reasons for changes visible and allows decisions before a delay affects advertising or other business plans.