Most small-business websites take somewhere between two and eight weeks to plan, design, build and launch. A very simple site can be finished faster. Ecommerce, booking systems, large content migrations and custom integrations can take several months.
The interesting part is that the coding is often not what decides the finish date.
Projects usually slow down because the content is not ready, photographs are missing, nobody has final approval, requirements keep changing or a third-party integration takes longer to test than expected.
A realistic UK website timeline depends more on readiness than page count.
A focused five-page business site with final content and one decision-maker can be live in one to three weeks. A more bespoke project usually takes four to eight weeks. Ecommerce and integration-heavy projects often run eight to sixteen weeks or longer.
How long does each type of website usually take?
| Project | Typical working range | What usually affects it |
|---|---|---|
| One-page site | A few days to 2 weeks | Content readiness and revisions |
| 5-page brochure site | 1–4 weeks | Copy, imagery, design approval |
| Professional SME site | 4–8 weeks | Strategy, copy, templates, integrations |
| WooCommerce or booking site | 6–12+ weeks | Products, payments, stock, booking rules, testing |
| Large or custom build | 3–6+ months | Bespoke development, migrations, multiple stakeholders |
These are planning ranges rather than promises. Two five-page sites can have very different schedules if one uses final supplied content while the other needs research, copywriting, photography and a booking integration.
Why do agencies quote longer timelines than the actual build time?
Because “two weeks of work” does not always mean two consecutive calendar weeks.
Agencies and freelancers usually run several projects at once. Your project may move through design, feedback, content, development and testing in scheduled blocks rather than receiving one person’s uninterrupted attention every day.
That is not automatically inefficient. It is how service businesses manage capacity.
The useful question is whether the quoted timeline is explained clearly. A six-week schedule should show what is happening during those six weeks rather than leaving four of them as unexplained waiting time.
Where does the time actually go?
A professional website project normally has six stages.
1. Discovery and scope
This is where the provider learns what the business sells, who the customer is, what the website must achieve and what functionality is required.
For a straightforward small-business site this may take a meeting and a day or two of planning. For a larger project it can involve workshops, stakeholder interviews and technical discovery.
2. Sitemap and content planning
The page structure should be agreed before detailed design begins.
Which pages exist? Which service gets its own page? Are location pages needed? Where do case studies sit? What information belongs on the homepage rather than the service pages?
A good website brief removes many of these decisions before the project clock starts.
3. Content and assets
This is frequently the longest uncontrolled stage.
The designer needs final or near-final copy, logos, brand files, photographs, service information, testimonials, team details, legal text and any downloads or product data.
When those arrive in pieces over three weeks, the project moves in pieces too.
4. Design
For a small site, design may take a few days to two weeks depending on how bespoke the layouts are and how many review rounds are included.
The efficient approach is usually to establish the visual system and main page types first, then apply that system across the remaining pages.
5. Development and integrations
This is where the approved design becomes the working site.
Simple brochure pages can be built quickly. The schedule expands when the site needs ecommerce, booking rules, APIs, CRM integration, membership, multilingual content or migration from an existing platform.
6. QA, launch and monitoring
Testing should cover more than whether the pages open.
Forms, mobile layouts, analytics, redirects, SEO settings, checkout, confirmation emails, accessibility basics, browser behaviour, speed and backups all need attention before launch.
Content is usually the biggest source of delay
Websites are made of content. Yet content is often treated as something that can be added after the design is finished.
That creates rework.
A layout designed around two lines of placeholder text may fail when the actual service explanation needs six paragraphs, a comparison table and three customer questions.
Projects move faster when the content is ready before detailed design begins because the designer is solving the real page rather than a placeholder version of it.
How much of the timeline depends on the client?
More than most businesses expect.
A typical project needs the client to:
- approve the sitemap;
- supply or approve copy;
- provide photographs and brand assets;
- give access to the domain, hosting and analytics where relevant;
- review designs;
- answer questions about services and customer journeys;
- test the staging site;
- approve launch.
If every decision needs to pass through four people, the calendar expands even if the actual production work does not.
One decision-maker can save weeks
Projects often become slow when feedback arrives from several people separately.
One person says make the heading larger. Another says smaller. A third rewrites the section. The agency makes a revision, then discovers the first stakeholder was not consulted.
A better system is to nominate one final decision-maker and submit consolidated feedback at agreed points.
That does not mean only one person can have an opinion. It means the provider receives one resolved set of instructions.
Why does ecommerce take longer?
An ecommerce website is not simply a brochure site with product cards.
It may need:
- product data;
- variations;
- stock rules;
- tax settings;
- shipping zones;
- payment gateways;
- discount logic;
- transactional emails;
- account pages;
- returns information;
- analytics and purchase tracking;
- real checkout testing.
Each part creates another path that needs to work correctly.
The development may still be straightforward, but the testing surface is much larger.
Why do booking systems and integrations add time?
Third-party systems create dependencies outside the designer’s direct control.
A CRM may need credentials from another supplier. A booking platform may require account configuration. A payment gateway may need verification. DNS changes can require access from an IT provider.
Those dependencies should be identified during scoping rather than discovered the week the site is supposed to launch.
Can a professional website really be built in a week?
Yes, under the right conditions.
A one-week build is realistic when:
- the scope is small;
- the provider has capacity;
- the page structure is already agreed;
- content and photographs are ready;
- there is one decision-maker;
- no complicated integrations are involved;
- feedback comes back immediately.
A short timeline becomes a problem only when the provider is achieving it by skipping work the project actually needs.
There is a difference between an efficient process and a rushed process.
What gets cut when a project is rushed?
Usually the least visible work:
- discovery;
- content review;
- mobile QA;
- accessibility checks;
- SEO migration planning;
- form testing;
- analytics setup;
- cross-browser checks;
- post-launch monitoring.
The homepage can still look finished. The missing work appears later when enquiries do not arrive or old rankings disappear.
How can you make a website project faster without reducing quality?
Speed comes from removing unknowns, not removing checks.
Finish the brief before kick-off
Agree the page list, functionality and responsibilities in writing.
Prepare copy early
Even rough final copy is more useful than polished placeholder text that will later change shape.
Gather all assets in one place
Logos, fonts, photographs, testimonials, accreditations, social links, access details and legal information should not be arriving through ten separate email threads.
Freeze the launch scope
If a new idea appears halfway through, decide whether it is essential for launch or belongs in phase two.
Agree feedback deadlines
If the provider returns a design on Tuesday and feedback arrives ten days later, those ten days belong in the project timeline.
Test as you go
Do not leave every mobile, form and content issue until the final afternoon.
How long does a five-page website take?
A focused five-page site can often be completed in one to four weeks when content is ready and the functionality is straightforward.
The 5-page website cost guide explains how the scope affects price. The same variables affect time: bespoke design, copywriting, photography and integrations add work even when the page count stays at five.
Does a redesign take longer than a completely new site?
Sometimes.
An existing site creates useful assets, but it also creates migration work. URLs may need preserving or redirecting. Existing content has to be audited. Analytics and search performance should be benchmarked. Old forms, plugins or integrations may need replacing.
The website redesign cost guide goes deeper into that scope, but the important timeline point is simple: redesigning something that already has search history can require more planning than building a small first website from scratch.
When should you set the launch date?
Set a target date at the beginning, but do not make the launch date more important than the launch criteria.
If the contact form still does not deliver, the site is not ready because the calendar says Friday.
A useful launch plan identifies:
- target date;
- content deadline;
- design approval date;
- staging review period;
- final QA date;
- who gives go-live approval;
- who is available immediately afterwards.
How long after launch before the website starts producing results?
That is a different timeline.
A website can be technically complete on launch day. Search visibility, reputation and conversion data take longer to develop.
Existing businesses migrating a ranking site may already have demand arriving on day one. A brand-new business on a new domain may need time to build search visibility and other acquisition channels.
Do not confuse “website finished” with “marketing finished”.
What should happen in the first month after launch?
The site should be watched, not abandoned.
Check:
- forms and enquiries;
- analytics;
- Search Console indexing;
- 404 errors;
- mobile behaviour;
- page speed;
- conversion paths;
- feedback from real customers and staff.
The most useful improvements often become obvious only after real people start using the site.
How we scope timelines
Our web design service in London treats the timeline as a consequence of the agreed scope rather than choosing an arbitrary number of weeks first. A small prepared project can move quickly. A migration or ecommerce project needs enough time to test what can actually break.
Frequently asked questions
Can a five-page website be built in two weeks?
Yes. It is realistic when content is ready, the design scope is focused and decisions are made quickly.
Why do some agencies quote 8–12 weeks?
They may include more discovery, content, bespoke design, testing and project-management time, or they may schedule the work around several projects. Ask for a phase-by-phase plan rather than judging the number alone.
What is the biggest cause of website-project delays?
Content and slow decisions are among the most common causes. Missing copy, photographs and approvals can stop design and development even when the supplier has capacity.
Does ecommerce always take months?
No, but product data, payments, shipping, stock, customer emails and integrations create more testing than a brochure site. Simple stores can move quickly; complex ones need more time.
Should I launch if a few small things are unfinished?
That depends on what they are. Minor cosmetic refinements can often wait. Broken forms, checkout, redirects, analytics, security or indexability should not.
Clear scope, finished content, available assets and fast approvals remove far more time than rushing development ever will.
