Cost and time are the two questions every business asks before commissioning a website, and while plenty of pages will give you a price, the timeline answers you find tend to be a vague "it depends" or a suspiciously tidy "two weeks". Both are unhelpful for the actual decision you are making, which is usually anchored to something real: a launch, a season, a rebrand, an event with a date on it.
So here is the honest version, from an agency that builds websites for a living: what each type of project takes, where the weeks go, and the one factor that separates projects that land on schedule from projects that drift.
How long does a website take to build in the UK?
These are realistic 2026 timelines from project kick-off to launch, assuming a prepared client and a clear decision-making process. They match the ranges we quote and schedule for our own projects.
| Project type | Typical timeline | What stretches it |
|---|---|---|
| Brochure site (4 to 6 pages) | 4 to 6 weeks | Content arriving late, slow feedback rounds |
| Custom business website (5 to 15 pages) | 6 to 12 weeks | Integrations, copywriting from scratch |
| Ecommerce store | 10 to 16 weeks | Product data, payments, shipping and stock integrations |
| Large or complex build | 12 to 20+ weeks | Custom features, multiple systems, approval layers |
Worth saying plainly: a competent freelancer or agency can produce a simple template site much faster than the bottom of that table, sometimes in days. The table describes properly built custom projects, where design starts from your business rather than a theme, and where the site is expected to earn its keep for years. If someone quotes you two weeks for a bespoke ten-page build, the missing weeks come out of discovery, content or testing, and you will meet them again after launch.
Where do the weeks go?
A website project is a chain of dependent phases, and most of them are invisible from the outside. For a typical custom business website, the schedule looks like this:
- Discovery and planning: 1 to 2 weeks. What the site needs to achieve, who it speaks to, what stays from the old site, what the structure will be. The cheapest week of the project to spend and the most expensive to skip.
- Design: 2 to 4 weeks. Wireframes first, then visual design, with a feedback round on each. Two focused rounds of feedback move faster than five vague ones.
- Content: runs alongside everything. Copy, photography, product data. This phase has no fixed length because it is mostly not in the agency's hands, which is exactly why it decides the schedule.
- Build: 3 to 6 weeks. The designs become a real, working website: pages, CMS, integrations, the lot. Usually the longest single phase, and the quietest, which unnerves clients who expect constant visible change.
- Testing and launch: 1 to 2 weeks. Devices, browsers, forms, checkout journeys, redirects, analytics. The unglamorous fortnight that separates a launch from an apology.
Add those up and the middle of the table above stops looking conservative and starts looking like arithmetic. Two more things belong in any honest schedule: slack, because a plan with no room for a late photo or one extra feedback round is a bet rather than a plan, and a defined post-launch window, because small fixes always surface once real visitors arrive and handling them is part of the project rather than a favour.
What do the fastest projects have in common?
We notice the same three things every time a project lands early or exactly on schedule, and none of them are about the agency working faster.
The content exists before the build needs it. Finished copy, chosen photography, product data in a spreadsheet rather than in someone's head. Projects that start with content ready can run design and build back to back instead of pausing between them.
One person can say yes. Projects with a single decision-maker, or a pair who agree quickly, move through feedback rounds in days. Projects where every design goes to a committee move in weeks, because five opinions produce revision rounds that reopen decisions already made.
Feedback arrives while the project is warm. A design review returned in two days keeps the team in context and the momentum up. The same review returned in three weeks means re-familiarising, re-scheduling, and usually a slot behind whichever project did respond.
None of this is a complaint: it is the practical answer to "can it be done faster?" Yes, and the lever is preparation on your side of the table, not overtime on ours.
What slows a website project down?
The mirror image of the list above, and worth naming because every one of these is avoidable.
Late content is the big one, and it deserves its reputation: a build that is ready for copy that does not exist yet is a build on pause. Reopened decisions are the quiet one: changing the sitemap in week seven undoes work from weeks two through six, which is why a good agency seems so insistent about sign-off early on. And unavailable people are the seasonal one: a project spanning August or December needs the holiday calendar built into the schedule, not discovered by it.
If your project is a redesign of an existing site rather than a new build, the same logic applies with one addition: migrating content and protecting your Google rankings adds real work to the schedule. Our guide to what a website redesign involves covers that process, including realistic timelines of 12 to 20 weeks for larger sites.
How much of the timeline needs you?
The question behind the question, and the one agencies rarely answer in advance: what will this project cost you in time, not money?
For a typical custom build, plan for a concentrated involvement at the start: a discovery conversation or workshop, plus the thinking it prompts about what the site needs to achieve. After that, your time comes in short, scheduled bursts: a feedback window on wireframes, another on visual design, and reviews as built pages appear. Each one needs days of turnaround, not hours of effort. The steady background job is content: gathering, writing or approving it, which is the one workstream that runs the whole length of the project.
The useful planning move is naming your own busy periods at the briefing stage, the same way you would name a launch date. A project scheduled around your trade show, your year-end or your school holidays keeps its feedback windows realistic, and a schedule everyone can keep is worth more than an ambitious one nobody can.
Why is "how fast" the wrong first question?
Speed matters, but it is the second question. A properly built website is a three-to-five-year asset: the difference between a ten-week build and a fourteen-week build disappears within months of launch, while the difference between a rushed build and a considered one compounds for years, in rankings, conversion and how much the site costs to change later.
The better first questions are the ones that decide the timeline: what does the site need to achieve, what content exists, who makes decisions, and what real date is it working back from? Bring those four answers to any competent agency and you will get a schedule you can plan a business around, rather than a guess dressed up as a promise.
Working towards a date?
Tell us what it is. We build our schedules backwards from real deadlines, and we will tell you plainly whether yours fits, what it needs from you to fit, or when the honest start date is if it does not. See how we approach web design and ecommerce, or get in touch with your date and we will take it from there.
Get in touch - we're happy to chat.



