Timeline
How long does it take to build a business website?
Your new branch has an opening date. The proposal says the website takes a month, but does that include the copy, photography and testing the enquiry form? Until those details are clear, the estimate is difficult to use in your launch plan.
EO Labs publishes indicative ranges of 1–2 weeks for a compact website, 2–5 weeks for a corporate website and 4–8 weeks for advanced interactive work. These describe our project formats, not a market-wide average. The actual date depends on scope, content readiness and approvals. Here is how to assess the estimate before work begins.
The ranges currently published by EO Labs
The table uses the same indicative ranges as our services page. They help match a task to a project format, but do not replace a project-specific estimate. A corporate website with prepared content needs a different plan from one whose services still need defining and whose internal systems need connecting.
Before work begins, agree what the selected format includes and which additional tasks affect the schedule. Adding a few weeks to today's date is not enough to turn these ranges into a confirmed launch date.
Scroll the table horizontally
| Format | Indicative range | Purpose |
|---|---|---|
| Compact website / landing page | 1–2 weeks | For one offer and a short route to enquiry. |
| Service business website | from 1–2 weeks | For services, terms, trust, coverage and a clear next action. |
| Corporate website | 2–5 weeks | For a company, its services and several audiences. |
| Advanced visual / interactive project | 4–8 weeks | For products that need a distinctive, complex presentation. |
Find out when the clock starts
Signing the agreement, delivering the content and approving the structure are different starting points. If design begins only when the copy arrives, and nobody has been assigned to write it, the launch date is still unresolved.
Separate confirmed information from possible features. An approved service list is something the team can work with. A suggestion to add a customer account area still needs decisions about user roles, available actions and the source of the data. Those are different levels of readiness.
Ask what can begin now, what is blocked and who can resolve each dependency. You may discover that the next useful step is a content and planning exercise rather than starting the whole development project.
Put reviewable results in the schedule
Design, development and launch are broad labels. Design might cover only the homepage, or all the main templates and their mobile states. Launch might mean uploading files, or handing over a tested website with working enquiry delivery.
Write down what you will review at each milestone. Approving the homepage, a service page and the form on wide and narrow screens is more specific than approving the design. The next stage should follow a clear decision rather than an informal expression of approval.
Scroll the table horizontally
| Stage | Result to review | What it depends on |
|---|---|---|
| Structure | The page list and route to an enquiry | The offer and the questions visitors need answered |
| Content and design | Copy and the main templates, including mobile | Service information, assets and an approver |
| Development | Working pages, forms and agreed integrations | Approved states and access to external services |
| Testing and publication | Completed journeys, domain setup and enquiry delivery | Final content and acceptance criteria |
Allow for decisions as well as production work
The time a supplier spends doing the work is different from the calendar time to launch. A finished design may be waiting for a director to review it. That wait is not additional design work, but dependent tasks may still move.
Assign one person to collect feedback and return a decision the business has agreed. If marketing wants a shorter form, sales wants more fields and the director sees both ideas just before launch, the team has conflicting instructions to resolve.
Agree how to submit feedback: one list with priorities and an explanation of the problem. Correcting a phone number is different from dividing a service into several new pages. The latter can change approved work and needs its own assessment.
Check what can run in parallel
Photography and collecting service information can often proceed alongside planning the structure. Finalising a page layout, however, depends on what it must contain: a simple price, a set of conditions or a comparison table. Placeholder copy does not always support a final design decision.
Check external services early. A CRM integration needs more than the product name: the team needs access, agreed fields and someone who can confirm receipt. If the connection is first tested just before publication, its limitations become a late project dependency.
Ask which chain of tasks determines the launch date. Finishing an illustration sooner will not unblock a service page that still needs a decision on its content. The next unresolved dependency is usually more useful to discuss than an overall percentage complete.
Work backwards from a fixed opening date
Define the first release for the actual event. A new branch may need its address, opening hours, services and a way to book. A careers section or detailed company history might be able to follow later, provided the business can operate without them at launch.
Make that reduction in scope explicit. Record what will be published, what will follow and how the later pages will fit. A design with a non-working booking journey is not a usable first release if taking bookings was its main purpose.
Leave room between finishing the pages and launching
Follow the visitor journey on a phone and a computer: find a service, understand the terms and send an enquiry. Test missing or invalid information, error messages and actual delivery to the person handling requests. A success message in the browser does not establish that the business received anything.
Agree who connects the domain, checks the published website, receives the handover and fixes any issues found. When replacing an existing website with different addresses, plan the relationship between old and new pages as a separate task.
Publication and appearance in search are separate events. The team can check that a crawler can access the pages, but cannot control the date they will be included in search results. Keep a promised indexing date out of your own sales plan.
Questions to settle before agreeing the date
Ask for these answers in the proposal itself. If answering them requires more work on the brief, agree the scope before committing to a date.
- Which event starts the delivery period?
- What content and decisions does our team need to provide?
- Which pages and functions belong to the first release?
- Who approves each milestone, and what happens while an answer is pending?
- Which external accounts and integrations need an early check?
- What makes the website ready to launch, and who checks the published version?
Further documentation
Does your website need to be ready for an event?
Include the date, essential pages and available content in your brief. We can discuss the first release and its dependencies before design begins.