Why the Honest Answer Is a Range
Timelines are quoted with false precision because clients ask for a date and vendors want the work. The truthful version is that a website's duration is set less by how long the work takes and more by how quickly decisions get made. Two identical projects with identical teams routinely finish four weeks apart, and the variable is almost never the build.
Below is what each phase actually contains, how long it takes when things go normally, and where the weeks disappear when they do not.
Realistic Timelines by Project Type
| Project type | Typical duration | Compressed, if everything is ready |
|---|---|---|
| Landing page or microsite | 2 to 3 weeks | 1 week |
| Marketing site, 5 to 8 pages | 6 to 10 weeks | 4 weeks |
| Larger marketing site with CMS | 10 to 14 weeks | 7 weeks |
| E-commerce store | 10 to 16 weeks | 8 weeks |
| Custom platform or web application | 4 to 9 months | rarely compressible |
| Redesign with migration from an existing site | add 2 to 4 weeks | not advisable to compress |
Phase by Phase: Where the Time Goes
Phase 1 — Discovery and definition (1 to 2 weeks)
What happens: understanding the business, the audience and the commercial goal; auditing the current site if one exists; agreeing scope, sitemap and success criteria in writing.
This phase feels like a delay and is the cheapest insurance in the project. Every week saved here reappears later as a rebuild. The deliverable should be a document that lets a stranger build the right thing — not a slide deck restating your brief back to you.
Phase 2 — Content and structure (2 to 4 weeks, runs in parallel)
What happens: writing or gathering copy, sourcing photography, defining what each page must say before deciding how it looks.
This is the phase that sinks timelines. Design cannot be finished around content that does not exist, and "we will fill that in later" reliably becomes a three-week hold at the worst possible moment. Start it on day one, in parallel with discovery, not after design.
Phase 3 — Design (2 to 4 weeks)
What happens: art direction, key page designs, then the remaining templates and states — mobile, empty, error, loading.
Two rounds of revision is normal. A third suggests the direction was not agreed properly at the start. More than three usually means feedback is coming from people who were not in the discovery conversation.
Phase 4 — Build (3 to 8 weeks)
What happens: front-end development, CMS setup, integrations, responsive implementation, performance work.
The most predictable phase, provided design is genuinely signed off. Design changes during build are the expensive kind, because they invalidate work already done rather than work not yet started.
Phase 5 — Testing and QA (1 to 2 weeks)
What happens: real-device testing, browser checks, accessibility review, form and integration testing, performance measurement, content proofing.
This is the phase clients most often agree to shorten under deadline pressure, and it is the one whose absence is visible to every visitor thereafter. If the timeline has to compress, cut scope instead.
Phase 6 — Launch and stabilisation (a few days, plus 2 weeks of watching)
What happens: DNS and hosting cutover, redirects from old URLs, analytics and tracking verification, search console submission, then monitoring.
For a redesign this phase carries real risk — the mechanics of protecting rankings through a cutover are covered in our guide to redesigning without losing search traffic, and the diagnostic if pages fail to appear is in why a site does not show up on Google.
The Three Delays That Cause Most Slipped Projects
1. Content arriving late
The single largest cause, by a wide margin. The fix is unglamorous: agree a content deadline in the contract, treat it as a milestone with the same weight as a design sign-off, and decide in advance what happens if it is missed — usually that the project pauses and re-enters the schedule when content arrives, rather than compressing the phases after it.
2. Feedback by committee
Five stakeholders each sending separate contradictory notes turns a two-day revision into a two-week negotiation that the studio cannot resolve. Appoint one person who consolidates internal opinion and speaks with a single voice. This one change is worth more calendar time than any process improvement a studio can make.
3. Scope added after sign-off
"Could we also add a blog?" is a reasonable request and a three-week change. Every addition is legitimate; what causes the damage is treating additions as free in time as well as money. A clear change-request process makes the trade explicit: this is possible, it costs this, it moves launch by this much, do you want it?
How To Genuinely Go Faster
- Have copy written before design begins. The largest single lever available to you.
- Reduce unique templates. Eight pages sharing three layouts is far faster than eight bespoke ones, and usually better designed.
- Appoint one decision-maker with real authority, available weekly.
- Get access sorted in week one — hosting, domain, analytics, any third-party accounts. Chasing credentials in week eight is a common and avoidable stall.
- Launch in phases. A strong core site live in six weeks beats a complete one in fourteen, and real traffic teaches you what to build next.
- Defer the nice-to-haves explicitly to a phase two, in writing, rather than arguing about them during phase one.
What a Fast Quote Usually Means
If someone quotes two weeks for a project everyone else quotes at eight, they are describing different work: a template, your content dropped in, no testing beyond a glance, and no migration plan. That is a legitimate product at the right price. It is not the same product, and comparing the two on duration alone is how buyers end up disappointed by a service that delivered exactly what it promised.
Kalex Studio quotes timelines against a written scope with named client-side milestones, so the dependency is visible from the start rather than discovered in week six. If you need a date for a specific project, send us the brief and we will map the schedule.