For a standard small business website, about three to four days from the point we have your content.
The honest version of that answer is that it depends on you more than it depends on us. If you reply quickly and get us what we ask for, three to four days is realistic. If replies take a week each time, the project stretches, and there isn't much a developer can do about that.
That's not a complaint. It's the single most useful thing to understand before you start, because it means the timeline is largely in your hands.
Here's where the time actually goes. If what you are really trying to work out is the budget rather than the calendar, how much a website costs in Canada is the more useful read.
Why Nobody Can Give You an Exact Number
Building the site is the predictable part. We've done it enough times to know roughly how long a page takes.
What isn't predictable is everything that has to come from your side, and that's where the variation lives.
Two businesses can order an almost identical website on the same day. One is live by the end of the week. The other is still not finished months afterwards. The difference usually isn't the website at all. It's how quickly each of them answered their email.
So when someone quotes you a guaranteed date without asking a single question about your content or your availability, treat it carefully. They're either padding the estimate heavily, or they're planning to build something generic that doesn't need anything from you.
What the Three to Four Days Actually Consists Of
It's worth knowing what you're waiting on, because most of it isn't what people expect.
A conversation first
Before anything gets designed, we need to understand what your business is, who you serve, and what you want the site to actually do.
This is short, and it's the part that saves the most time later. A site built without it tends to need rebuilding halfway through.
Design and build
This is the bulk of the work and the most predictable part of the schedule. You see progress as it goes rather than waiting for a reveal at the end, so anything heading in the wrong direction gets caught early instead of after everything is finished.
Launch and handover
Pointing the domain at the new site, checking it on real phones, getting it set up so search engines can find it, and showing you how to run it.
Usually a day, occasionally more if the domain is somewhere awkward.
What Actually Makes It Take Longer
In our experience it is nearly always one of three things, and none of them are the building.
1. Waiting for content and photos
This is the big one, by a distance.
The design is done, the pages are built, and the whole thing sits waiting on the text about your services or photos of your actual work.
It's completely understandable. Writing about your own business is genuinely hard, and it's the kind of job that gets pushed to the weekend and then to the weekend after that.
But a finished website with nothing to put in it cannot launch, and this is where most of the lost weeks go.
2. Slow approvals
We send something over to check, and then the project pauses until we hear back.
A day is normal and expected. A week each time, three or four times over, quietly turns a short project into a long one without anybody ever deciding that should happen.
It gets slower again when several people at the business need to agree before anyone replies.
3. Third-party accounts
The one nobody expects, and the one most likely to hold up a launch on the actual day.
Usually it's one of these:
- nobody can remember who registered the domain or where,
- the login for it belongs to someone who left the business,
- a payment provider is verifying the business and takes days to do it,
- or access to an existing Google listing has to be recovered first.
None of these are anybody's fault and all of them are outside a developer's control. They're also the easiest to solve early, which is why we ask about them at the start rather than the week you want to go live.
When the Delay Is Our Fault
Everything above puts the timeline on your side of the table, so it's only fair to say the other half.
When a project drags, some of that is usually on us.
If we didn't ask clearly enough what we needed at the start, or asked for it in five separate messages over three weeks instead of once at the beginning, that's not the client being slow. That's us running the project badly.
A business owner should not have to work out what a web developer needs from them. Being told up front, in one list, is most of the difference between a project that runs to schedule and one that doesn't.
It's the part of this job we think about most, and it's why the first conversation matters more than it looks like it should.
How to Make It Fast
If you want this done quickly, almost all of the leverage is in the first few days.
Before the build starts, have ready:
- a rough version of what you want each page to say, even if it's messy,
- photos of your real work rather than stock images,
- your logo, in the best quality you have,
- your services and, if you publish them, your prices,
- and the login for wherever your domain is registered.
Rough is fine. Rough can be edited. Missing cannot.
The other thing that helps is deciding in advance who gives feedback. One person with the final say moves several times faster than four people who all need to weigh in.
Should You Be in a Rush at All?
Worth asking, because plenty of people set themselves a deadline that nothing is actually driving.
If you have a real date, a season starting, a location opening, an event coming up, then say so at the beginning. It changes how the work is sequenced.
If you don't, there's usually no prize for launching four days sooner.
And if you do need something live quickly, the honest lever is building less rather than building faster. A good four page site now, with more added later, beats waiting on twelve pages of text that haven't been written. The site starts working for you while the rest gets finished.
Final Thoughts
Three to four days of build time is a fair expectation for a small business website once your content is in hand, and the calendar around it is something you have more control over than your developer does.
The projects that run long are almost never the ones with complicated websites. They're the ones where the content never quite got finished, or where a reply took a fortnight, or where nobody could find the domain login until the day of launch.
All three of those are solvable in an afternoon at the start, and nearly impossible to fix once the project is already late.
If you're getting quotes, ask what the developer needs from you and when they need it. Anyone who can answer that clearly has thought about your timeline. Anyone who can't probably hasn't.