How long it actually takes to build a website

How long it takes to build a website depends almost entirely on what kind of website you’re building. A WordPress brochure site takes one to three months. A bespoke WooCommerce build sits between two and four months. A headless ecommerce platform on BigCommerce or similar rarely lands under six. If an agency is quoting a timeline well outside the range for the type of build you’ve described, ask what’s been left out of the estimate rather than why it’s different.

Most of what makes a build take the time it does is predictable. Some of it is platform-driven and effectively fixed. Some of it is decision-making bottleneck, and very much not. Below are the ranges we see across UK agency work on standard, well-scoped projects, the rough shape of where the weeks go inside them, the things that quietly add months, and the questions that pressure-test a quote before you sign.

What a realistic website build timeline looks like

The ranges below assume cooperative stakeholders, content that arrives roughly when it should, and a scope that doesn’t materially shift mid-build. They’re practitioner ranges, not best-case marketing numbers, and they cluster reasonably tightly across competent UK agencies working on the same type of project.

A few of those ranges deserve a comment.

The brochure WordPress band covers most small business marketing sites, and it varies more than any other category. The variable is almost always content. A 12-page site with a marketing manager who has copy and imagery ready can ship in four to six weeks. The same site, with content written from scratch and signed off by committee, can stretch to three months without anyone behaving badly. Other templated platforms aimed at the same brief, Webflow and Squarespace in particular, cluster in the same band: tightly templated builds ship faster, customisation pushes timelines toward the upper end. If the choice between CMS options is still open, our comparison of WordPress and Webflow for a business website covers the decision in depth.

The 6–12 month range for CraftCMS international school sites isn’t padding. These sites typically run to tens or hundreds of pages, potentially in multiple languages, with translation cycles, image rights to clear, SEO architecture to migrate across language variants, and several internal team members to onboard. The technical build is rarely the long pole. Content and stakeholder choreography is.

Headless builds carry a baseline overhead monolithic builds don’t. The architecture is genuinely more complex. Front-end and back-end are decoupled, more moving parts sit at integration, and the QA matrix expands accordingly. A headless CMS build of broadly equivalent scope to a monolithic WordPress site will typically take half again as long. Sometimes longer.

Replatforms are case-by-case in a way other builds aren’t. A move from one templated platform to another, with a small product catalogue and no integrations, can be done in three to four weeks. An enterprise migration off Magento with thousands of SKUs, three integrations and historical SEO equity to preserve is a six-month project before discovery has finished.

Where do the weeks in a website build actually go?

Inside a 12-week WooCommerce build, the rough shape is consistent enough to plan against.

Discovery typically runs a few weeks. That covers stakeholder interviews, technical audit if there’s an existing system, scope confirmation, and the production of a written brief that both sides sign against. Discovery is the single most leveraged phase in the build, and the one most often compressed or skipped to win a quote on price. We have a separate piece on what discovery actually means and when it’s worth paying for if you want to go deeper.

Design lands at around three weeks. Wireframes, key page comps, design system documentation, two rounds of feedback. Three weeks is a working number for a 10–15 page site with one design system. Larger sites or more design-led briefs push this out further.

Development runs three to five weeks for a build of that size. This is the part most buyers think of as ‘the build’, and it’s also the part where the work is most visible to the agency and least visible to the client. Weekly demos or a staging environment update should be standard.

Content loading is the wildcard. We’ve seen 12-week builds run on time because the client delivered all copy and imagery in week three. We’ve seen identically scoped builds stretch by six weeks because content turned up in week ten. The agency does not control this phase, and any honest project plan flags it as a dependency rather than an estimate.

QA and UAT take roughly a week. Cross-browser, accessibility, performance, integration testing, and a structured user-acceptance cycle with the client. A week is the floor. For anything transactional, two is more honest.

Launch itself is a few days. Monitoring afterwards is anywhere from a week to a few months, and the budget should reflect that. A site doesn’t end when it goes live. It ends when post-launch issues have been triaged and the analytics baseline is clean.

A six-month headless build follows the same shape, but the proportions shift. Discovery expands to three or four weeks because the architecture decisions are more consequential. Development becomes the dominant phase by a clear margin. QA gets disproportionately more time because the integration matrix is larger. Content can still sink the timeline regardless of how technically clean the build is.

What makes a website build run late?

Some of the things that move a timeline are largely outside anyone’s control. Others are entirely within the buyer’s control and, when handled well, are the difference between an on-time launch and a six-month overrun.

The technical drivers are the ones most discussed in proposals and least responsible for slippage. Integration count is real: every CRM, ERP, payment gateway, or third-party API adds time, especially when the third party has its own release cycle and its own support response times. We’ve seen builds delayed by weeks waiting on a single CRM vendor to update or clarify its API documentation. Those delays are uncomfortable, but they’re typically priced in by experienced agencies, who will pad the integration phase explicitly in a Gantt chart.

The genuinely punishing drivers are the avoidable ones, and they sit on the buyer’s side.

Content readiness is the biggest. A build with finalised copy and imagery in hand before design starts will move through feedback rounds noticeably faster, because designers are designing against real content rather than placeholder lorem ipsum. A build that loads content in conjunction with design and development creates two feedback loops where there should be one.

Stakeholder count is the second. There is a clear breaking point around two or three approvers, beyond which every sign-off cycle becomes a coordination exercise rather than a decision. We’ve watched single projects gain a stakeholder in week six, when someone senior is suddenly looped in, and lose three weeks re-baselining decisions that had already been signed off. Naming a single decision-maker on the buyer’s side, with delegated approvers underneath, is the structural fix.

Sign-off process is the third. An agency that gets feedback within 48 hours of a milestone keeps momentum. An agency that waits two weeks for a response on wireframes is, by week eight, behind on a build that hadn’t slipped in any technical sense.

A recent multi-application CraftCMS migration handled by Bristol-based agency Parrot Creative ran exactly to its planned timeline. The project covered three integrated applications, a non-trivial data migration, and a published handover. Upfront documentation kept it on track: technical specifications, handover documents, migration risk assessments, a dependency map across the three applications, and a properly maintained project management software. A week of front-loaded documentation prevented at least four weeks of mid-project ambiguity.

The counter-example is more common. A bespoke API integration project we observed recently lost more than six months for none of the reasons normally blamed for delays. The technical scope wasn’t unusually hard. The agency wasn’t underpowered. Mid-build, the client’s project manager changed, and because the scope had been agreed verbally across a long-running relationship rather than in writing, the incoming PM began revising decisions that had been made months earlier. Half a year on, the project still hasn’t launched. The lesson generalises: written scope matters most exactly when both sides feel the relationship is too established to need it.

How to spot an unrealistic timeline

A quoted timeline significantly shorter than the ranges above usually means one of three things. The brief has been misunderstood. The quote has been under-scoped. Or a phase the build needs has been quietly removed.

There are four specific signals worth treating as serious.

No discovery in the quote. A bespoke build without a discovery phase is a build that hasn’t been scoped. The agency has either decided to absorb discovery into design, which means corners get cut on both, or they’re pricing against a brief they don’t fully understand. Either way, the timeline is fictional. The same dynamic, applied to price rather than time, is the subject of our piece on why agency quotes vary so much.

No design phase. A quote that jumps from kickoff to development is a quote from an agency that builds in WordPress page-builders against off-the-shelf themes. That’s a legitimate model for very small marketing sites with a buyer who’s genuinely happy with a templated outcome. It is not a viable model for a bespoke build. Any agency claiming otherwise is selling something other than what you asked for.

No QA period. If the timeline runs from ‘development complete’ to ‘launch’ inside a few days, QA isn’t happening. Cross-browser testing, accessibility audit, performance testing, integration testing, and structured UAT cannot be compressed into a long weekend. The bugs the build is shipping with will surface in the first month of live use, at which point fixing them is more expensive than catching them.

Less than two months for anything bespoke. This is the cleanest smell test. Any quote claiming a four-to-six week turnaround on a custom build is either redefining ‘bespoke’ to mean ‘theme with a logo swap’, or quietly assuming you’ll accept whatever comes out at the end. A genuinely custom build, even a small one, needs the time the phases above require. The arithmetic doesn’t compress.

The pattern across all four is the same. The agency that wins on timeline is often the agency that’s removed work from the quote you can’t easily see is missing. Six months later, you find out.

How to pressure-test a timeline before you sign

The questions worth asking are short, and the answers tell you more than the timeline itself does.

Ask the agency to walk you through the timeline phase by phase, in weeks. A confident agency will do this without referring to notes. A vague agency will reach for generalities like ‘we’ll know more after kickoff’. The latter is fine for a small templated project. It is not fine for a six-figure build.

Ask to see a similar project, at a similar size, that they delivered in the timeline they’re proposing. Not a case study on their site. A phase-by-phase reference, ideally with a contactable client. An agency that can produce one within a week is an agency that delivers on time. An agency that can’t is an agency where you’re going to be the first.

Ask what happens if content arrives late. The honest answer is some version of ‘we’ll continue on the technical build, but the launch date moves’. An agency that claims content delays won’t affect timeline is either not telling you the truth or planning to launch with placeholder text.

Ask who on your side has sign-off authority and how feedback loops will run. If the agency hasn’t asked you this, they will be surprised in week six when the head of marketing wants three rounds of changes on copy the marketing manager has already signed off.

Ask what the change request process is, and what it does to the timeline. A change request mid-build should be priced and re-baselined. If the agency says ‘we’ll absorb it’, they are either eating margin they cannot afford to eat, or they will find the time back somewhere you won’t notice until QA.

Honest agencies welcome or ask these questions. They are the questions a well-run client asks, and a well-run client is the kind of project an agency wants. An agency that bristles at being asked to defend its timeline is an agency that doesn’t expect to hold to it.