Quick answer: the build itself takes days. A landing page with a settled structure and finished copy comes together in a few working days; a company site of five to fifteen pages in one to two weeks of actual work. Calendar time from the first conversation to launch is longer: usually two to three weeks for a landing page and four to eight for a company site. The gap between those numbers isn't work — it's waiting for copy, photographs, replies and decisions. With materials prepared and one person deciding, a landing page can go live in a week.
When people ask how long a website takes, they usually have one number in mind. In practice there are two, and the gap between them is wider than it looks.
Development is rarely the bottleneck: code gets written predictably and quickly. Projects stall for a different reason — waiting for copy, photographs, or a decision nobody is available to make. So the timeline quoted to a client is made of work plus idle time, and the second part is usually the larger one.
Below is a breakdown of both: how long the build itself takes, what makes up the calendar time, and what you can prepare in advance to close the gap.
The build and the calendar: two different numbers
The build itself is days. A landing page with an approved structure and finished copy comes together in a few working days. A five-to-fifteen page company site takes one to two weeks of actual work. It's the most predictable and most controllable part of the project.
Calendar time is weeks. From the first conversation to launch: discussing the brief, copy and materials, design and approvals, development, testing. Usually two to three weeks for a landing page, four to eight for a company site.
The gap between them is waiting. Not build complexity, not the contractor's workload — idle time: a week for copy promised "tomorrow", three days for a mockup to be approved, waiting on photographs from a photographer.
Which gives the practical conclusion worth the whole article: calendar time shrinks not by speeding up development but by removing the pauses. With materials ready, one person deciding and quick replies, a landing page can realistically launch in about a week — and that isn't quality traded for speed, it's the absence of gaps.
What makes up the calendar time: the stages
Reference points for a project of moderate complexity at a normal approval pace.
Discussing the brief and structure — a few days to a week. Goals, audience, what the site has to do, which pages are needed and how they connect. The stage that saves weeks later if it's done properly.
Copy and materials — a week to several weeks. The least predictable stage, because it doesn't depend on the contractor. More on this below.
Design and mockups — one to three weeks. Depending on how many unique page layouts there are and how many rounds of revision.
Development — one to four weeks. Build, functionality, integrations, populating content, configuring the admin panel.
Testing and launch — a few days to a week. Checks across devices, speed, forms, markup, indexation.
Add them up and you get the four to eight weeks for a company site. A landing page follows the same path, just shorter: usually two to three weeks.
- Brief and structure — Few days — a week — Both sides
- Copy and materials — A week — several weeks — The client
- Design and mockups — 1-3 weeks — The contractor, revisions with the client
- Development — 1-4 weeks — The contractor
- Testing and launch — Few days — a week — The contractor
Why calendar time is more often missed by the client
This isn't a complaint — it's a consequence of how the process works.
A contractor can't finish the services page without knowing what goes on it. Can't assemble a project section without photographs. Can't move on until a mockup is approved. Each of those moments halts not one task but the whole chain, because the stages are linked.
The most common story goes like this: the project starts briskly, hits the copy after a week — copy the client promised "tomorrow" — and sits for three weeks. In the report it looks like a long build, though there were five days of work in it.
A separate word on revisions. One or two rounds are a normal part of the process. A fifth round with a change of concept is a new project paid for as the old one, and it always comes out of the timeline.
Why copy is needed before design, not after
The common sequence — "design it first, we'll write something later" — sounds logical and costs weeks.
A layout built around real copy and a layout built around placeholder text are different things. When the real copy arrives it turns out to be longer or shorter, the heading doesn't fit two lines, and the advantage the design promised isn't in the text at all. Reworking the layout starts, and reworking the build follows.
The reverse order saves time twice over: the designer works with actual content, and the page structure grows out of meaning rather than the other way round.
The practical conclusion: if there's no copy, it's better to push the start back a week and prepare it than to formally begin and block the project for a month.
What to prepare before the start to shorten the build
A checklist that genuinely shortens calendar time — in my experience often by half.
Copy for each page, or at least the key points: what the service is, who it's for, how it differs, what it costs, what happens next.
Photographs. Your work, your premises, your team. In most fields real photographs persuade more than any copy, and preparing them takes longer than expected.
Logo and brand colours, if you have them, in source files.
Access credentials: domain, hosting, analytics, the old site. It usually turns out the access sits with a previous contractor, and that's a separate week-long story.
A list of services in the form you want to sell them, not the form they exist in your head.
Reviews and credentials: certifications, licences, memberships, case studies.
One person who decides. The most underrated item. Sign-off through three managers with different tastes extends a project more reliably than any technical complexity.
What extends a website build beyond plan
Scope changes mid-project. "While we're at it, let's add another section" — each addition drags structure, design and testing along with it.
Multiple approvers. Every additional participant adds a revision round and time spent gathering opinions.
Waiting on third parties. A photographer, a copywriter, a lawyer, a data provider — they run on their own schedules.
Integrations. Connecting to a CRM, payments or a booking system depends on someone else's API and its documentation; timelines here are harder to predict.
Migration from an old site. If the site has rankings, moving it means not just a transfer but a redirect map, preserved markup and verification after launch. Add a week or two minimum, and cutting corners here is dangerous.
Language versions. Each is not only translation but a separate structure and separate testing. What multiplies isn't just the volume of text but the checking.
Can a website be built faster, and what does that cost
It can, and there are two honest ways.
Reduce the scope. Launch fewer pages and add the rest afterwards. This works well: the site starts earning sooner, and you learn what's actually needed.
Prepare in advance. Everything in the checklist above. It's the only way to shorten the timeline without losing anything.
And two approaches that look like speed but aren't: skipping testing, and taking a template instead of a structure built for the task. The first means visitors find the bugs. The second can be a reasonable decision, but it's a different product rather than the same one delivered sooner.
Separately: if a contractor quotes half the timeline everyone else does, ask what isn't in it. The answer is usually the planning stage, the testing, or everything that makes the site findable.
How long a build takes with me
A landing page — from a week, if the copy and materials are ready and one person makes the decisions. In the usual case, where some of the material is assembled along the way, it's two to three weeks from the first conversation to launch. A multi-page company site — longer, depending on the number of pages, features and languages. Migration from an old site and multilingual structure add time, and I say so at the start rather than during the work.
The spread between one week and three depends not on my workload or on how complex the build is, but on how many times the project ends up waiting for you.
I give the timeline after discussing the brief, broken into stages, and I say in advance which of those stages will be waiting on you. That isn't a formality: a client who knows copy will be needed in a week prepares it in advance, and the project doesn't stall.
I combine development and SEO, so the optimisation stage isn't added at the end as a separate block — it's distributed through the work.
Where to start if the site is needed by a deadline
Reduced to one principle: the timeline is set not by development speed but by your readiness at the start.
A practical step: take the checklist above and honestly mark what you have right now. If more than half the items are empty, the real timeline will be noticeably longer than any quoted figure — and it's better to know that before starting than a month in.
And one question worth asking before all the others: is the offer defined? If the business hasn't settled what it sells and to whom, a website won't resolve that, and the timeline will stretch on exactly that point.
If you'd like a realistic timeline for your own project, write to me and we'll break it down by stage.
