How Long Does a Website Take?

How Long Does a Website Take?

How long will it take?

It’s a fair question, not to mention one of the first questions people ask when they are thinking about a new website.

Businesses need to plan around launches, campaigns, internal deadlines, funding windows, events, seasonal demand and all the other moving parts that sit around a website project.

The frustrating answer is that, really, it depends.

This is not because we enjoy being vague and mysterious, but because a website timeline is shaped by far more than the time it takes to design and build.

It is fairly obvious that a small one-page website will take less time than a large site with multiple page types, integrations, stakeholders and approvals. But in our experience, the biggest delays rarely come from the build itself.

They usually come from the decisions around the website.

What needs to go on it?
Who is writing the content?
Who is approving it?
Are the services clear?
Are the images ready?
Is the old content still accurate?
Has everyone agreed what the website is actually supposed to do?

Those questions have a much bigger effect on timelines than most people expect.

The Build Is Only One Part of the Project

When people ask how long a website takes, they are often thinking about design and development.

This makes sense, as these are the most visible parts of the work, but there is a lot that needs to happen before you can reach that stage.

Someone needs to understand the business, the audience, the pages required, the key journeys, the calls to action and the role the website needs to play.

The structure needs to be agreed, the content types need to be understood, the design system needs to be in place and any technical requirements need to be clear.

A website project usually includes some or all of the following:

• discovery and planning;
• wireframing;
• content gathering;
• copywriting or content refinement;
• design;
• development;
• CMS setup;
• content population;
• integrations;
• testing;
• client review;
• final amends;
• launch preparation;
• domain and hosting setup;
• post-launch checks.

Some of those stages can overlap; some depend on others being finished first.

That is why two websites with the same number of pages can take very different amounts of time.

One might be clear, well-prepared and easy to move through.

The other might uncover unclear services, missing content, old photography, internal disagreements and three technical dependencies nobody mentioned at the start.

On paper, they might both look like “a new website” but in practice, they are very different projects.

Content Is Usually the Biggest Variable

Content is where website timelines often slow down.

This is not a criticism of clients. It is just the reality of what content creation and curation involves.

At the start of a project, content can feel like a fairly simple task. You need words for the pages, some images, a few team bios, a handful of case studies and maybe some FAQs.

But then you start gathering it and suddenly, the service descriptions are out of date. The team page needs rewriting. The case studies are not finished. The photography is from five years ago. The testimonials are sitting in someone’s inbox. The pricing has not been agreed. The old website has pages nobody wants to keep, but nobody is quite ready to delete.

This is where a website project stops being just a design job and becomes much more about clarity.

Content forces a business to make decisions about how it explains itself:

What do you actually offer?
Who are you trying to reach?
Which services matter most?
What proof do you have?
What should people do next?
What needs to be removed, rewritten or made clearer?

Those decisions can take time and, if they are not made early enough, they affect everything else.

While the website may be technically ready, a project cannot move properly if the content is not.

“We’ll Sort the Content Later” Usually Causes Problems

Like all rules, there are times when this can be broken to good effect. But one of the easiest ways to slow a website project down is to treat content as something that can be dropped in at the end.

Get the design done first. Build the site. Add the content later.

The problem is that content shapes a website.

A service page with two short paragraphs needs a very different design from one with detailed sections, FAQs, case studies, testimonials and enquiry routes.

A case study area needs to be structured around the kind of stories the business can actually provide.

A resources section depends on what types of content will be published and how people need to filter or browse it.

Even a homepage depends heavily on what the business is able to say clearly.

If the design is created around vague placeholder text, there is a good chance it will need to be changed once the real content appears, which is not efficient for the client or the developer.

That is why content should be treated as part of the project from the beginning. Even if placeholder content is used, it needs to be discussed properly so there is at least a sensible idea of what the final page will need to hold.

Feedback Can Move a Project Forward or Slow It Down

Feedback is another big part of the timeline.

Good feedback helps a project move quickly. It is clear, specific and gathered in one place. It explains what needs changing and why.

Difficult feedback tends to arrive in fragments.

One person replies by email. Someone else comments in a document. Another person mentions something on a call. A new stakeholder appears late in the project and wants to revisit decisions that were already approved.

That is where timelines start to stretch.

This is especially common when there is no clear decision-maker.

A website can have several people involved, but there still needs to be a person or small group responsible for pulling feedback together and making final decisions.

Without that, projects can get stuck in loops.

The issue is not that feedback exists. Feedback is useful and absolutely necessary. The issue is when nobody is accountable for it, or when the feedback starts to conflict with itself.

Scope Changes Add Time

Most website projects evolve slightly as they develop.

This is completely normal and understandable. Trying to imagine everything a website will need before seeing a single pixel is not easy.

Once people see wireframes, designs or early builds, they often understand the project more clearly. New ideas come up. Better ways of structuring pages appear. A feature that felt important at the start may become less relevant, while something else becomes more useful.

Some change is healthy, and sometimes required, but larger changes affect timelines.

Adding new page types, new functionality, new integrations, extra approval stages, complex forms, resource libraries, booking tools, ecommerce features or member areas will usually add time.

That is not because anyone is being difficult. It is because those things need to be planned, designed, built, tested and managed properly.

The earlier those requirements are known, the easier they are to account for. The later they appear, the more likely they are to affect the launch date.

Technical Details Can Hold Things Up Too

Some delays are less exciting.

Domains. DNS. Hosting. Email records. Analytics access. CRM logins. Booking systems. Payment providers. Newsletter platforms. Old website redirects. Cookie tools. Privacy policies. Third-party scripts.

None of these sound like major creative decisions, but they can hold up a launch if nobody knows where the accounts are, who has access or what needs to be connected.

This is particularly true for established businesses with older websites. We have had plenty of projects where the final stumbling block has been accessing a domain account set up ten years ago.

The domain might have been bought by someone who has since left the business. Analytics might be under an old Gmail account. The booking system might need support from a third-party provider. The old site might have important pages that need redirecting properly.

A good website process should flush those things out early.

They are much easier to deal with calmly before launch week, trust me!

A Realistic Timeline Depends on Readiness

So, how long does a website take?

A simple website with a clear brief, agreed structure and ready content might take a few weeks.

A more involved bespoke website will usually take longer, often several months, especially if there are multiple stakeholders, custom functionality, content migration, integrations or a larger amount of content to shape.

But the more useful question is not only:

“How big is the website?”

It is:

“How ready is the project?”

A small website can take a long time if nobody has agreed what it needs to say and a larger website can move surprisingly smoothly if the structure is clear, the content is prepared and decisions are made at the right time.

How We Approach Timelines

At Wilkes Wood, we try to remove as much uncertainty as possible before design and development get too far ahead.

That means starting with discovery, structure and wireframes, rather than jumping straight into polished visuals.

We ask clients to appoint a single point of contact, so feedback can be gathered clearly and decisions do not get lost between different people, documents and email threads.

We want to understand what the website needs to do, how the pages fit together and what content will be needed before the build begins.

For content, we use a clear gathering process so clients can see what is required, what has been provided and what still needs attention. We have also created a guide that explains how best to deliver content to us, so the build process can move as efficiently as possible.

We encourage content to be marked as final before it moves into build. That does not mean a website can never change, but it does avoid the worst version of a project: designing and building around content that is still being rewritten in the background.

The aim is not to make the process rigid for the sake of it, it is to protect the timeline, the budget and the quality of the finished website.

The Honest Answer

A website takes as long as the work requires.

I know that might sound obvious, but it is the truth.

Design and development matter, of course. But the timeline is also shaped by how clear the brief is, how prepared the content is, how quickly feedback is handled and how many decisions still need to be made.

A good agency should be able to give you a sensible estimate, but a good client-side process matters too.

The more clarity you bring into the project, the smoother it will be; the more content, decisions and approvals are left open, the harder it becomes to predict.

So when you ask how long a website takes, the answer is not just about the number of pages or the complexity of the built, it's about readiness.