The honest answer to “how long will the website take” depends on what kind of website you mean, how much of the content already exists, and how many people need to sign off. The realistic answers are also longer than most clients expect, and shorter than most agencies claim.
This piece sets out the actual timelines for the three most common kinds of web build, the variables that move the dates, and the four most common reasons projects slip past their promised launch dates.
The three kinds of build
Most websites we get briefed on fall into one of three buckets, each with very different timelines.
Marketing sites
A marketing site is what most businesses mean when they say “website”: homepage, a handful of service or product pages, an about page, a contact page, maybe a blog. Five to fifteen pages of content. The job is to communicate, not to transact.
Realistic timeline from brief to launch: four to eight weeks.
A four-week marketing site is achievable if all of the following are true: the brand exists already, the content is mostly written, there is one decision-maker, and the scope is genuinely under ten pages. An eight-week version covers most real-world projects – including time for content development, two rounds of design review, and a launch window with QA on real devices.
E-commerce builds
A real e-commerce build – payment, inventory, shipping, tax, accounts, the works – is a different animal. Even a “simple” Shopify or similar build with 50 products and three shipping zones is genuinely a four to eight week project, not a long weekend.
Realistic timeline: eight to sixteen weeks for a Shopify build with custom theme, content, and basic integrations. Sixteen weeks plus for a headless build or one with significant integrations into ERP, fulfilment or loyalty systems.
The two things that consistently blow e-commerce timelines: photography (the brand often underestimates the time to produce 200 product shots) and back-of-house integrations (the inventory feed that the supplier promised “is just an API call” turns out to be a CSV emailed weekly).
Web apps and custom builds
If the site is doing something genuinely custom – a booking platform, a member portal, a data dashboard, a directory with search and filtering – we are no longer in marketing-site territory. These are software projects.
Realistic timeline: twelve weeks to six months, depending on scope. The honest answer is that anyone who tells you they can build a custom web app in four weeks is either underestimating the scope or planning to ship something that will need rebuilding within a year.
For the rest of this piece, the timelines and advice assume a marketing site. The principles apply to the other two, but the specifics differ.
What a four-week marketing site actually looks like
Four weeks from “go” to launch is achievable. Here is the rough cadence:
- Week 1. Kickoff, structure sign-off, content audit. By end of week the sitemap, page templates and content plan are locked.
- Week 2. Wireframes and copy drafts. By end of week the structure and key messages on every page are signed off.
- Week 3. Visual design, build starts in parallel. By end of week the design direction is locked and the technical foundation is in place.
- Week 4. Full build, content load, QA, launch. By end of week the site is live and we are watching analytics.
Four-week timelines depend on three things being true. The client has one decision-maker. The content is either ready or will be written quickly. There are no major integrations (payment, booking, CRM). Miss any of those and the timeline stretches – not because the studio is slow, but because the actual work is bigger.
What an eight-week marketing site looks like
Eight weeks is the comfortable timeline for most real-world projects. It gives time for:
- Discovery and strategy (week 1-2). What does the site need to do, for whom, against which competitors, with which content. Usually a workshop, some stakeholder interviews, a written brief.
- Architecture and content (week 2-4). Sitemap, page wireframes, copy drafts. Content is where most projects either accelerate or stall – it is by far the most underestimated workstream.
- Design (week 3-5). Visual design in parallel with content. Two review rounds.
- Build (week 4-7). Front-end implementation, CMS setup, integrations.
- QA and launch (week 7-8). Real-device testing, performance optimisation, content load, redirects from the old site, DNS cutover, post-launch monitoring.
Notice that several phases overlap. That is deliberate. Sequential phases (design must be 100% done before build starts) are how four-week projects become twelve-week ones.
What moves the timeline
Six things explain most of the variance between similar projects.
1. Content readiness
This is the single largest variable. A project where the client says “we’ll write the content” but hasn’t started often slips by three to four weeks. Content writing is genuinely time-consuming. If you have not done it before, budget twice as long as you think.
The fix: either commit copywriting resource on the client side from day one, or include copy in the project scope from the studio. There is no third option that works.
2. Number of approvers
A project with one decision-maker moves twice as fast as one with three. A project with a steering committee moves three times as slowly. Each approval round adds days, not hours – not because anyone is being slow, but because calendars are real and the time to consolidate feedback is real.
The fix: appoint one person with final say. Other stakeholders can input, but only one signs off.
3. Integrations with existing systems
CRM, marketing automation, customer support, analytics, payments, inventory. Each integration adds time – not because the API call is hard, but because the discovery work is often skipped at brief time and surfaces mid-build. “We use HubSpot” is a sentence; making the website talk usefully to HubSpot is a week of work.
The fix: write down every system the website will need to talk to, before the project starts, and include them in the brief.
4. Brand state
A clean, working brand identity speeds the design phase enormously. An incomplete or inconsistent brand means the website project also becomes a brand project – which is fine, but it adds three to six weeks. The honest answer is often “we should do the brand work first, then the website,” even if the timeline pressure is on the website.
5. Quality of input assets
If the client is providing photography, video, testimonials, logos and copy, the timeline depends on when those arrive. Late assets are the most common reason for week-by-week delays. We try to get a full asset audit done in week one of every project, so we know exactly what is coming, when, and from whom.
6. Scope creep
The classic culprit. “Could we also add…” can be a fine question or a project-killing one. The difference is whether the additional scope was anticipated in the original quote. We use a written change-of-scope process on every project, so adding a section adds a known number of days and rand, rather than absorbing silently into the timeline.
Why projects slip
Of the projects that miss their launch date, the reasons cluster into four buckets:
- Content not ready (about 50% of slippages). Already discussed above. Almost always solvable by including copywriting in the project scope.
- Approval bottlenecks (about 25%). Usually a single stakeholder who is travelling or unavailable when a review is needed. Solvable by scheduling reviews in advance and naming a deputy.
- Integrations more complex than briefed (about 15%). Solvable by an integrations audit before the project starts.
- Scope creep (about 10%). Solvable by a written change-of-scope process.
Notice that none of the top four reasons are “the studio was slow”. That is not because studios are never slow – we are sometimes slow – but because studio capacity is usually the smallest variable in the equation. The big variables are on the client side.
How to give your project the best chance
Three things to do before you brief, regardless of which studio you go with:
- Write a one-page content audit. List every page, what content exists, what needs to be written, and who will write it. If the answer to “who will write it” is “we will figure it out”, the project will slip.
- Name one decision-maker. Tell the studio who has final say. Make sure that person is available during the project window.
- List every integration. CRM, payments, analytics, anything. Write down the version and the person who manages it. If you don’t know, find out before the project starts.
If you do those three things, your project is statistically much more likely to launch on time than the average. They are unglamorous and they take a few hours, and they make the difference between a four-week project and a twelve-week one.
If you are scoping a website project and want a fast read on what timeline is realistic for what you have in mind, send a short note describing the business, scope and timing. We will give you an honest range, including the variables that would push it shorter or longer.