How long a website actually takes, and what makes it late
A five-page small-business website takes two to four weeks. A custom fifteen-page site with original copy and photography takes six to twelve. Anything with booking, payments or a system to talk to takes three months or more. Almost every project that runs late runs late for the same reason, and it is not the build.
Ask three people how long a website takes and you will get three answers, because they are each imagining a different project and a different client. The build is rarely the slow part. What makes projects late is almost always the same short list, and most of it is decided before anyone writes a line of code.
Realistic timelines
Working days, assuming the client responds within a day or two and nothing unusual happens.
| What you are building | Realistic time | The long pole |
|---|---|---|
| Five-page site, content ready | 2–4 weeks | Design approval |
| Five-page site, content to write | 4–6 weeks | Getting the copy right |
| Ten to fifteen pages, custom | 6–12 weeks | Content volume |
| Anything with booking or payments | 12 weeks+ | The integration and its testing |
| Rebuild of an existing site | 3–8 weeks | Deciding what to keep |
If somebody quotes you five days for a real business website, they are either using a template with your logo dropped in, which is fine when it is stated, or they have not thought about content. Ask which.
Where the time actually goes
A typical five-page build breaks down roughly like this.
Understanding the business: two to four days. What you sell, who buys it, what they ask before they buy, and what you want more of. Skipping this is what produces a site that looks fine and generates nothing.
Design: one to two weeks. Including your review. This stage should end with you approving something you have actually seen, because changes here cost a conversation and changes after the build cost real money.
Content: one to three weeks, in parallel. Writing, photographs, the details nobody thinks about until asked, like your exact opening hours over holidays. This is the stage that overruns.
Build: one to two weeks. For a straightforward site, on sensible foundations, this is the most predictable part of the whole project.
Launch: two to five days. Moving the domain, setting up email, checking it on real devices, and watching it for a few days afterwards. Domain moves have waiting periods nobody controls, which is why this is never same-day.
The four things that make projects late
Waiting for content. This is the big one, by a wide margin. The build finishes and then sits for three weeks waiting on photographs, or a services list, or a decision about what to call something. If you do one thing before hiring anybody, gather what you already have.
Too many approvers. A project with one decision-maker moves. A project where three people have to agree and none of them owns it can add a month, and the month is spent on email rather than on the website.
Changing the brief mid-build. Adding a booking system in week four does not add a booking system, it restarts the design. That is not a supplier being difficult, it is that the pages have to work differently.
Chasing the builder. The one you cannot plan around. It is also the reason worth asking about references, and the reason to know who built your website and whether you can still reach them before you are relying on it.
What you can do before you hire anyone
Every hour spent here comes off the project, and none of it is wasted if you end up going elsewhere.
Gather what exists: logo files in their original format, photographs of the actual business, any copy you are happy with, and the login for your current site if you have one. Find out who controls your domain, which is often a genuine investigation and always better done now than during launch week. Decide who approves the design, one person, by name. And write down the three questions customers ask you before they buy, because that is the site’s job and you are the only one who knows them.
What a fast build actually looks like
Fast is not the same as rushed. A build moves quickly when the scope is fixed before it starts, the content exists, one person approves, and the thing being built is a website rather than a piece of software with a website attached.
That is most of why our entry build has a stated timeline at all: it is a five-page site with a defined scope, so the estimate means something. It is usually live within twenty business days of the first payment, and the clock pauses whenever we are waiting on you rather than running against you for it. The web design service page sets out what each stage covers, and the pricing page has the numbers.
A custom fifteen-page build with original photography does not get a promise like that, because it would not be true.
Can it be done faster?
Sometimes, and it is worth knowing what you are trading.
You can genuinely compress a build by cutting scope. Four pages instead of eight, one round of design review instead of three, your existing photographs instead of a shoot. That is a real decision with real consequences and a good supplier will help you make it rather than pretend the same site can arrive in half the time.
What does not work is compressing by working longer hours, which produces the same site later and worse. Nor does running stages in parallel that genuinely depend on each other: building pages before the design is approved means building them twice, and everybody involved knows it while it is happening.
The honest version of a rush job is a smaller job. If you need something live in ten days, the answer is a three-page site that does one thing well, launched now and grown afterwards. That is a legitimate strategy rather than a compromise, and it beats a half-finished ten-page site by a distance.
Working backwards from a date
If you have a date that matters — a season, an opening, a campaign that is already booked — start from it rather than from today.
Take your date and subtract a week. Nothing launches on the day it is finished, because domain moves have waiting periods and you want a few days of watching it before it matters. Then subtract the build, then the content, then the design, then the fortnight it takes most businesses to gather what they already have. For a five-page site that is about eight weeks before the date, not four.
Two timings are worth avoiding outright. Do not launch into your busiest fortnight of the year, because the one thing you cannot afford that week is a surprise. And do not schedule the content stage across a holiday period, because that is the stage that depends entirely on you being available to answer questions.
If the date is already too close, cut scope rather than stages. Skipping the understanding stage to save four days is how you arrive on time with a site that does not work.
The short version
Two to four weeks for a small site with content ready, six to twelve for something custom, three months or more once anything has to integrate. The build is not the slow part. Content and approvals are, and both are on your side of the table, which is genuinely good news: they are the parts you can fix before you even choose who to hire.