How long does a website take? A realistic project timetable
How long a website takes is decided not by the designer’s speed but by five factors: the number of pages, whether the content is ready, how quickly sign-offs come, special functions such as booking or reservations, and the number of languages. A small business site with its copy and images ready, and quick decisions, can typically be ready to launch in a few weeks. If the copy is written from scratch, there are special functions or the site is bilingual, that can stretch to several months.
Below we open up each factor, walk through the stages in order, and share five ways to avoid delay.
Why “how many days?” has no single answer
Two people ask the same question. One wants a five-page introductory site and has the copy ready on the desk. The other wants thirty service pages, a journal, a booking flow and an English version — and not a line of copy exists yet.
It would not be honest to give them the same answer. That is why a timetable comes not from a number offered before the scope is clear, but from a plan made once it is.
One more thing to say at the outset. What lengthens a project is rarely the code. It is copy still being written, an approval not yet given, a photograph that has not arrived, or a new request added halfway through. For a broader framework, see how long does a software project take? The principles there apply to websites too; here we focus more concretely on the website timetable.
The five factors that set the timetable
1. Number and types of pages
The number alone does not decide it. Ten pages move quickly if they are ten service pages sharing one template. Five pages take longer if each is a different page type with its own layout.
What matters is how many distinct page types the site has: home page, service page, team page, article page, contact page and so on. Each type is designed and built once. After that, adding more pages of the same type is much easier.
2. Is the content ready?
This affects the timetable more than anything else. If the copy, photographs, team details, service descriptions and frequently asked questions are ready, the work flows. If not, the design is finished and the pages sit empty.
Who writes the copy should also be settled from the start. You, us, or both together? We prefer to shape the copy with you. But since you know your business, the knowledge and the approval are needed either way.
3. Sign-off rounds and speed of decision
Each stage ends with an approval: the site map, the design direction, the page designs, the copy, the final check before launch. If each approval takes a week, a week is added at every stage.
The number of decision-makers matters as well. A project approved by one person moves faster than one where five people comment separately. Deciding at the start who has the final word is the simplest way to protect the timetable.
4. Special functions
A contact form is quick. A booking flow, reservations, menu filters, listings search, several calendars or a connection to another system all need more design, development and testing.
Each of these functions also raises the question of personal data: what information is collected, where it is stored, what the privacy notice says. Those decisions sit inside the timetable too. We cover booking separately in online booking systems, and write about sector-specific functions elsewhere: booking for psychologists and doctors, menus and reservations in restaurant website or QR menu?, and listings and project pages in websites for housing projects.
5. Number of languages
A second language is not a translation button in the corner of the page. It needs copy written separately or carefully adapted, correct addresses for each language, a language switcher, and markers that tell search engines which page corresponds to which in the other language.
Receiving and checking the second-language copy is a sign-off round of its own. If you are planning a bilingual site, say so in the first conversation.
The timetable, stage by stage
The table below shows the stages of a business website and what determines the length of each. The durations are relative; a firm figure goes into the written plan once the scope is clear.
| Stage | What happens | What shortens it | What lengthens it |
|---|---|---|---|
| Discovery and scope | Purpose, audience, page list and functions are discussed | One clear main purpose, a single decision-maker | Scope left vague |
| Site map and content plan | Which page answers which question is written down | Knowing the current site and what people search for | A page list that keeps changing |
| Design | The design direction, then the page types | Few page types, quick feedback | Many different layouts, long sign-off rounds |
| Content production | Copy, photographs, alternative text | Content already ready | Copy and images produced alongside the project |
| Development | Building pages, forms, special functions | A standard contact form | Booking, reservations, listings search, integrations |
| Testing and measurement | Speed, accessibility, mobile, forms, links | A structure built properly from the start | Pages and functions added at the last minute |
| Launch and early monitoring | Domain, redirects, search engine registration | Accounts and access ready | Domain and server access nowhere to be found |
Two of these stages can run in parallel: content production carries on whilst design is under way. If the content is ready, the longest stage is typically design and its sign-off rounds. If it is not, the longest stage is almost always content production.
We skip no stage — testing least of all. On every site we measure speed and accessibility before launch, and share the results with you. We explain why this matters in our technical SEO checklist.
If you are redesigning an existing site
Redesign projects add one more job to the timetable: finding out which pages of the old site receive visits and appear in search, and redirecting old addresses to their new equivalents. Skip it, and visibility built up over years can vanish in a short time.
That is why, on redesigns, we prepare an address-mapping list before launch, and watch the crawling and indexing reports for the first weeks afterwards. The details are in redesigning a website without losing SEO.
What comes after launch is part of the timetable too. A site is not finished on the day it goes live; small fixes, new pages and updates carry on. If you would rather not do this yourselves, we offer monthly maintenance after launch. We explain why it is needed in why website maintenance matters.
Why “a website in 48 hours” is not realistic
Most promises of this kind describe dropping a business name and a few photographs into a ready-made template. Technically, a page has gone live. But most of what you expect from a website cannot be done in that time.
In two days, it is hard to fit in all of the following:
- Content. Original copy that describes your services accurately and helps you be found in search.
- Structure. A site map setting out which page answers which question.
- Approval. The time you need to look at the design and copy and decide.
- Testing. Trying the site on phones, in different browsers, with a keyboard and with a screen reader.
- Technical foundations. Page titles, descriptions, the sitemap, structured data, redirects.
A quick start does sometimes have its uses — a temporary page showing only your name and contact details, for instance. But it should not be mistaken for a permanent business website. Fixing a site built in a hurry often takes longer than building it properly in the first place.
For our part, we do not use off-the-shelf themes. We build every site on a design system and produce static, fast pages. It is not a race. But built properly, a site is far easier to add pages to, update and grow later.
Five ways to avoid delay
- Start gathering content before the project. The list of services, team details, contact information, frequently asked questions and the real photographs you already have. Even rough versions speed things up.
- Name a single decision-maker. Comments can come from several people. But knowing who gives final approval stops the same point being reopened again and again.
- Settle the scope in writing. Which pages, which functions, how many languages? Sort new requests that arrive mid-project into “now” and “after launch”. Many are better handled in a second phase.
- Have accounts and access ready. Whose name are the domain, server, email, analytics and search accounts in, and who holds the passwords? Launch day is where this most often comes unstuck.
- Give feedback in one batch, on time. A single list for each sign-off round, rather than small corrections trickling in. Feedback that arrives on the agreed day is the surest way to protect the timetable.
Frequently asked questions
Can we start if my content is not ready?
Yes. The site map and design can run in parallel with content production. But the content sets the launch date. Pages fill as the copy arrives; the site is not complete until the last page’s copy is in.
Can we launch with a few pages and grow later?
Often that is a good route. You can launch with the home page, the core service pages and contact, and add the remaining pages over the following weeks. What matters is that the structure is built to grow from the start.
Do you give the timetable in writing?
Once the scope is clear, we share in writing the stages, what we need from you at each one, and estimated delivery dates. We also state plainly under what conditions the timetable might slip.
To pin down the scope of your site, see our web design and development page, or write to us with your sector, the pages you need and the functions you have in mind. We reply within two working days.