In brief
A website project for a service business typically takes six to fourteen weeks from kickoff to launch: roughly one to two weeks on discovery and structure, two to four on design, three to six on build and integration, and one to two on content, review and launch. The variation comes almost entirely from content readiness, the number of integrations and how quickly decisions get made — not from how fast the design or code can be produced. A project with content written, systems listed and one named decision-maker can launch in six weeks; one where those three things are missing routinely takes three months or more.
The timeline starts before design begins
The first one to two weeks are spent on discovery: understanding the outcome the site must deliver, who it has to convince, the action visitors should take, and what already exists. It feels slow because nothing visible is produced, but this is the stage that decides whether the rest of the work is efficient or repetitive. Skipping it does not save time — it moves the cost into redesign rounds later.
Structure follows the discovery work: the page list, the journey through it and the content each page needs. A clear structure is what lets design and build overlap instead of queueing, and it is what allows a content plan to start in parallel rather than after the design is signed off.
Design and build overlap when the plan is honest
Design usually takes two to four weeks depending on how many distinct layouts the site needs and how much the identity has already been settled. Reusing a design system across pages keeps this short; designing every page individually does not. Review rounds are where design time expands — three consolidated rounds of feedback are faster than eight scattered comments, even when the total number of notes is identical.
Build runs three to six weeks once the layouts are agreed: front-end work, the content management setup, and any integrations with booking, payment, calendar or CRM systems. This is the stage most sensitive to surprises. A system that appears after the build has started is rarely a small addition, because the architecture around it has already been chosen.
Content is where most projects lose their schedule
Projects rarely stall at design and almost never stall at code — they stall at content. Copy that still needs writing, photography that has not been commissioned, and facts that need checking by someone who is busy with other work can add weeks that no one planned for. A content plan agreed at kickoff, with names and dates attached to each page, is the single most effective schedule protection available.
The practical fix is to treat content as part of the build rather than a handover at the end. Draft the pages during design, gather the imagery early, and let the build work from real text instead of placeholder paragraphs. A site assembled with realistic content also reviews better, because you are judging the actual product rather than a layout filled with dummy copy.
Launch is a date, not the end of the work
The final one to two weeks cover final content entry, accessibility and cross-device checks, form and integration testing, analytics setup, and the redirect plan for any pages whose addresses change. This stage should not be compressed to hit a launch date — a broken enquiry form or a missing redirect is far more expensive than a launch two days later.
After launch, the site needs a short period of measurement and adjustment: checking where people drop out of the enquiry journey, fixing what the data shows, and reviewing the pages against the outcome the project was meant to deliver. Blacktide International plans website, brand and software delivery for service businesses in Glasgow and across the UK, United States and Europe — with a week-by-week schedule, one named decision-maker and a content plan agreed before design starts.