Guide Planning
How long does it take to build a website?
By Studio Swing
How long it takes to build a website depends less on the number of pages than on four things: how ready your content is, how quickly decisions get made, how many other systems the site must connect to, and whether an existing site has to be moved without losing what it has earned. A small site with finished copy and one decision-maker can move quickly. The same site with no copy, five approvers and a booking system to connect can take much longer, and the extra time is mostly waiting, not building. That is why any single figure you read online, including a confident one, tells you little about your project. The useful question is what your project's schedule depends on, and which of those things you control.
On this page
- 01A worked example: one clinic, two schedules
- 02What a website project actually involves
- 03Content readiness: a common delay
- 04Approvals: how many people decide
- 05Integrations: each connection is its own small project
- 06Migrations: moving a site that already has history
- 07Launch day itself has waiting built in
- 08Why we do not quote a typical figure here
- 09How to keep your project short without cutting corners
- 10What rushing costs
- 11A checklist before you ask anyone for a timeline
- 12Next step
- 13Sources

A worked example: one clinic, two schedules
Say you run a physiotherapy clinic and you are replacing a ten-year-old site. The new one needs about 15 pages, online booking through the system you already use, and the old site has 60 pages, some of which still bring visitors from search.
Version one. You have rewritten your service descriptions. Your practice manager can approve design decisions in a day or two. The booking system has a documented way to embed its calendar. Before anything is built, the old pages are listed, each one is given a decision (keep, merge, redirect or retire), and the redirects are prepared in advance. Design and build run without long pauses.
Version two. The copy has not been started and nobody owns it. Three partners each review every page, one at a time. The booking system turns out to need an account upgrade before it can be embedded, which takes its own time with the vendor. Halfway through, someone remembers the old site's blog posts. The building work is almost identical to version one. The calendar time is not.
The difference between the two schedules sits almost entirely outside the design and code.
What a website project actually involves
Most well-run projects pass through the same four stages, whoever builds them:
Discovery. Understanding the business, its customers, and what the site must achieve. For an important page, this ends in a written brief: what the page must say, who it is for, what it must prove.
Structure and content. Deciding which pages exist, what each one says and links to, and which customer searches each page should answer. The words get written here, not after the design.
Design and build. Designing and building every page, then testing it on desktop and phone.
Launch. Redirects from old addresses, tracking, final checks, and switching the domain over.
Each stage has work that only the studio can do and work that only you can do. Your parts (answering questions, supplying facts and photos, approving decisions) are the ones that most often set the pace.
Content readiness: a common delay
Design without real content is guessing. A page designed around placeholder text often has to be redesigned when the real text arrives, because the real text is longer, shorter or says something different. So content is often what holds a project up.
Content means more than body copy. It includes:
service or product descriptions with the facts a customer needs (what it is, who it suits, what it costs or how pricing works);
photos of your actual work, premises, products or team, with permission to use them;
prices, opening hours, delivery terms, policies;
answers to the questions customers ask on the phone every week.
If you will write the copy yourself, ask for page briefs that tell you what each page needs to say, so you are filling a defined space rather than starting from a blank document. If someone else writes it, agree who supplies the facts and who signs off the wording.
Approvals: how many people decide
Every round of review takes calendar time, even when each review is quick. Two things make it longer: more reviewers, and reviewers who see the work in sequence instead of together.
The fastest pattern is one decision-maker who gathers others' views and returns one consolidated set of comments per round. The slowest is several people commenting separately, sometimes in contradiction, with no one given the authority to settle the disagreement. If several people must be involved, decide at the start who has the final say on design, on wording and on what launches.
Integrations: each connection is its own small project

Anything the site must connect to adds steps that depend partly on someone else's schedule: a booking or appointment system, a payment provider, stock or accounting software, a customer database, a shipping service, a newsletter tool. Each one may need an account, settings, access for the developer, testing and sometimes a plan upgrade with the vendor.
Payments deserve a special mention for online shops. A payment provider usually asks for business and identity details before it will pay money out to you, and it checks them on its own timetable, not yours. Start it early.
Migrations: moving a site that already has history
If your current site gets visitors from search, the launch is not just a switch. Redirect each old address that moves to its new equivalent, or to a relevant page that genuinely replaces it. If a page is permanently removed with no suitable replacement, return a 404 or 410 status instead of redirecting it to an unrelated page. Listing every old page, deciding what happens to each and preparing the redirect records is real work, and it scales with the size of the old site, not the new one.
There is also a part nobody can rush. Google's own guidance on site moves says that "for medium-sized websites, it can take a few weeks or more" for Google to start showing the new addresses instead of the old ones, and that rankings may fluctuate while it recrawls the site. Google recommends keeping redirects in place "generally at least 1 year". Our guide to redesigning a website without losing search traffic goes through this in detail.
Launch day itself has waiting built in
Some launch steps have their own clocks:
Domain changes. When you point a domain at a new platform, the change can take time to reach everyone. Shopify, for example, tells store owners that "it might take up to 48 hours" for a connected domain to be fully live.
Search engines noticing. A new or changed page is not in Google's results the moment it goes live. Google says that after you ask it to recrawl, "crawling can take anywhere from a few days to a few weeks."
Checking it all. Forms, checkout, tracking, redirects and the mobile layout all need testing on the live address, not only on a preview.
This is why a careful launch is scheduled for a quiet trading period rather than the day before your busiest week. Google makes the same suggestion for site moves: move during your recurring traffic dips.
Why we do not quote a typical figure here
You will find many "typical" durations online. They are rarely comparable, because they measure different scopes: a template with supplied copy, a custom design with copy written from scratch, a 3,000-product store with a migration. A figure without its assumptions is not information. The useful version is a schedule for your project that states what it assumes (copy ready by a date, one approver, a working booking account) so you can see what moves it.
We do not publish a typical timing for our own projects either. Your scope is agreed in writing before any work starts.
How to keep your project short without cutting corners

Start the content before design starts, and give one person the job of finishing it.
Name one decision-maker, and agree how comments are gathered and returned.
List every system the site must connect to on day one, and check you have admin access to each.
If you are replacing a site, export a list of its pages and their search traffic early.
Start any payment provider or account verification as soon as you know you need it.
Keep the first version focused. A feature that can launch a month later should not hold up the launch.
Agree scope in writing before building begins. New ideas are welcome, but each one gets its own scope, so the original launch does not slide under them.
What rushing costs
The parts people skip under deadline pressure are the ones that are expensive to skip: the redirect list, testing on real phones, checking forms actually deliver, setting up tracking before launch rather than after. A site launched a week earlier without redirects can lose the search visitors that the old site took years to earn. If you have a fixed date (a trade show, a product launch, a new location opening), say so at the start, so the scope can be shaped to fit it rather than the checks being squeezed out.
A checklist before you ask anyone for a timeline
Checklist
- Do you have the copy, or a named person who will write it by an agreed date?
- Do you have photos you are allowed to use, or a plan to take them?
- Who has the final say on design, on wording and on launch?
- Which other systems must the site connect to, and do you have logins for each?
- Is there an existing site with search traffic, and how many pages does it have?
- Will you take payments, and has the provider verified your business yet?
- Is there a fixed date the site must meet, and why?
- When you receive a schedule, does it say what it assumes, and what happens if an assumption slips?
Next step
Our approach page shows the four steps we work through, each one approved by you, and what you receive at each one. Because time and budget move together, what affects the cost of a website is a useful companion read. To plan your own project, see custom website design. Then tell us about your project, and we reply with next steps. No cost, no obligation. Discuss your project
Sources
Google Search Central, "Site moves with URL changes": https:/
Google Search Central, "Ask Google to recrawl your URLs": https:/
Shopify Help Center, "Connecting a third-party domain to Shopify manually": https:/
