How long it takes to build a small business website is usually answered with a number of weeks and nothing else. The number on this site is two to three weeks, and that is a fair answer, but it hides the part that actually decides whether you hit it. The building is the short part.
This post uses something most agencies have and never publish: the complete, timestamped version history of this website. Every change ever made to it is recorded with a date, so the timeline below is measured rather than estimated. The repository itself is private, so what follows is the full extract rather than a sample.
Key Takeaways
- Calendar time and work time are different numbers: 185 days separate this site’s first commit from its most recent recorded change, and work actually happened on 33 of them. The gaps are the project, not the building.
- The build itself is days, not months: the current version went from its first line of code to live in three days and 62 recorded changes, because every decision had already been made and the content already existed.
- Launching and finishing are different events: this site was worked on across 22 separate days in the 100 days after it went live, against the three days that got it there.
- Content is the thing that decides your launch date. A build with no deadline for your photos and service descriptions does not have a launch date either, it has a hope.
A note on the numbers below. Everything described as measured comes from this website’s own version history, read as it stood on 19 October 2026, the date of the most recent change counted here. It is one site, built by the person writing this, so treat it as a worked example rather than an industry benchmark.
The external figures all come from a single source, the HTTP Archive’s annual Web Almanac, the one public dataset that measures what real websites are serving, at scale. It can only see sites as they stand when it crawls them, never how long any of them took to make, so every claim about weeks and phases here rests on the version history instead.
What Does the Two-to-Three-Week Build Window Actually Contain?
Two to three weeks, for a straightforward five-to-ten-page local business site with the design direction agreed up front. That is the lead time published across this site, and it is the number worth planning around. Larger builds with custom functionality run longer, and the reason is scope rather than typing speed.
What that window is actually made of:
- Direction and structure, a few days: deciding what the site is for, which pages exist, and what each one has to do before anyone designs a thing.
- The build itself, several days: the pages, the layouts, the mobile behaviour, the schema, the forms. This is the part people imagine is the whole project.
- Your content, the unpredictable part: photos of real work, real service descriptions, and the answers only you can give. This is where almost all overrun lives.
- Revision rounds, a few days: one or two passes of feedback, which go quickly when the direction was agreed up front and slowly when it was not.
- Launch and checks, one day: going live, confirming the forms send, submitting the sitemap, watching that nothing broke.
Your own time in all of that is a few hours, and gathering the photos is most of it. A kickoff conversation, sending your material, and one or two rounds of feedback is the rest. The ask is not large, and the delay is almost never its size, it is how long it sits unanswered.
What Does a Real Build Timeline Actually Look Like?
Here is this site’s, measured rather than remembered. It has had two complete versions, and the version history records the date of every single change, which makes the shape of a real project visible in a way a case study never is.
| Phase | When | Calendar days | Recorded changes |
|---|---|---|---|
| Build one, empty repo to live | Apr 17 to 20, 2026 | 4 | 21 |
| Launch fixes and first SEO pass | Apr 21 to 25, 2026 | 5 | 21 |
| Nothing happens at all | Apr 26 to Jul 8, 2026 | 74 | 0 |
| Full rebuild, first line to live (no client, content already written) | Jul 9 to 11, 2026 | 3 | 62 |
| Still being changed since | Jul 12 to Oct 19, 2026 | 100 | 82 |
The days column counts calendar days rather than days worked, and it counts each phase’s first and last day, so it totals one more than the 185-day span between the first and last change. Across those 185 days there were 33 days on which anything was actually changed.
The first version went from an empty project to a live site in four days and 21 recorded changes, including the schema, the sitemap, the robots rules and a working contact form. Five more days and 21 more changes covered the launch fixes and the first proper SEO pass. Then nothing happened for 74 days.
That 74-day gap is the most revealing thing in the table, and it is worth being clear that it was mine. No work, no changes, no progress, because attention was somewhere else. On a client project a gap like that is usually the owner and the designer each waiting on the other, and a designer with too much on is as likely a cause as a client who has gone quiet.
The current version is the striking one. It went from its first line of code to live in three days, across 62 recorded changes, and that included a complete redesign of every page on the site.
Three long days, not three ordinary ones: the version history records dates, not hours. Those three days are also not the same clock as the published lead time. They contain the design work itself with no approval step in front of them, while the two-to-three-week window starts once a client has approved a direction.
It was fast for reasons that are worth naming plainly:
- The content already existed: every word was already written and approved, because the previous version had been live for months.
- There was no approval loop: no waiting on feedback, no scheduling a call to decide a heading, no second opinion.
- The decisions were already made: the structure, the pages and the keyword each page targets had all been settled in advance.
- The person building it knew the material: no handover, no clarifying questions, no misunderstanding what a service actually is.
Remove those four conditions and you have a normal client project. That is the real lesson in the three-day number: it is what a build takes when nothing is waiting on anybody. Most of the difference on a client job is waiting, deciding and revising, and some of it is the building itself running slower while the builder learns a business they did not already know.
What Are the Phases of a Website Build?
Five, and only one of them is construction. Knowing which phase you are in tells you who the project is waiting on, which is the single most useful thing to know when it feels slow.
| Phase | Who does the work | What it produces | What stalls it |
|---|---|---|---|
| Direction | Both | Page list, keyword per page, design direction | Not knowing what the site is for |
| Content gathering | You | Photos, service descriptions, business details | An inbox nobody opens |
| Build | Your designer | The actual pages, mobile layouts, forms, schema | Missing content, changed scope, a designer who took on too much this month |
| Revision | Both | One or two rounds of fixes | Vague feedback, new people joining late |
| Launch and checks | Your designer | Live site, working forms, submitted sitemap | Domain and hosting access nobody can find |
One of those five phases is entirely yours and two more are shared. That is not a complaint about clients, it is the reason the published lead time is a range rather than a promise. The phases you own are the ones with no deadline attached unless somebody attaches one.
Notice what is missing from the stall column: difficulty. Almost nothing in a standard small business build is unpredictable, what goes on a service page is a known list, and the technical work behind it is routine. Projects run late because they are waiting, not because they are stuck.
Why Do Most Builds Take Longer Than the Quote Said?
Content. It is the answer often enough that any other explanation is worth a second look. The design gets approved, the build gets done, and then the whole thing sits waiting for photos and service descriptions.
What holds up a build is usually the same short list:
- Photos of real work: the single most common delay, because it means going back through a phone, or going out to take new ones. It is also the content that matters most, which is covered properly in what to show in construction website images.
- Processing those photos is a separate job from taking them: sizing and converting a folder of job photos is hours of work, and it is the corner a rushed build cuts. The Almanac found that “Most mobile pages have one image that’s 135 KB or more” and puts WebP at 12% of the web’s images, so serving heavy, unprocessed photos is still the norm rather than the exception (HTTP Archive Web Almanac, 2024).
- Real service descriptions: not a list of service names, but a few plain sentences each about what the job involves and who it is for. Nobody can write these for you convincingly.
- The boring business facts: service area, hours, licence and insurance details, which supplier logos you are allowed to show.
- Decisions only you can make: whether to publish pricing, which services you actually want calls about, what to do about the service you no longer enjoy doing.
- Access to things you already own: the domain registrar login, the current host, the Google Business Profile. Finding these is a surprisingly common week of delay, and it is one of the questions worth asking a web designer before you start.
The fix is unglamorous and it works. Agree a date for your material in the same conversation where you agree the price, and treat that date the way you would treat a supplier delivery. A build with no content deadline has no launch date.
For the list itself, item by item, what to send your web designer before they start sets out the full handover pack and what good looks like for each piece.
There is a second, quieter cause: changing your mind after the direction is approved. That is legitimate and sometimes right, but it is not free, and a second full round of revision costs the same days the first one did.
What Makes One Build Three Weeks and Another Three Months?
Scope, almost entirely. The number of pages matters less than whether anything on the site has to be built rather than written, because custom functionality is the one part that genuinely cannot be rushed.
- Page count moves the number gently: going from six pages to twelve adds days, not months, because the hard structural decisions are made once and reused.
- Custom functionality moves it a lot: anything interactive is a build inside a build. The World Food Equipment site runs a 3D walk-in cooler configurator alongside around 40 pages, and work like that is quoted per project for exactly this reason.
- Multiple decision makers multiply the revision rounds: two owners who disagree is not twice the feedback, it is a negotiation happening inside your project.
- Replacing an existing site adds a whole workstream: the redirect map, the URL inventory and the post-launch watch are real work, covered in replacing an old website without losing your rankings.
- Photography and copywriting from scratch add weeks: not because they are slow, but because they need scheduling, and scheduling is where calendars go to die.
A rough way to place your own project: the published starting point is two to three weeks for a standard five-to-ten-page site with the direction agreed. Anything interactive is quoted separately, because it is a build inside the build. Photography or copy that has to be made from scratch needs booking before the build starts, and that scheduling is what usually moves the date.
If you want a shorter build, the lever is not pressure on your designer. It is reducing what has to be decided during the project, by deciding more of it before the project starts.
Is Launch Day the Finish Line?
No, and planning as though it is produces a site that quietly goes stale. Launch is the point where real visitors start telling you things that no amount of planning would have.
This site has taken 82 separate recorded changes in the 100 days since its own launch, spread across 22 working days, which is a good deal more work than the three days it took to build it. Those changes were not fixes to a broken launch. They were the ordinary work of a site that is actually being used: new pages for searches that turned out to matter, copy rewritten once it was clear what people were reading, and features added as the business changed.
One example is worth the embarrassment, because it shows how real this churn is. A full-screen video homepage was built, reverted the same day it shipped, written off for good in the commit message, and then brought back about two and a half months later when there was better material to put in it. That is not indecision, it is a decision improving once it met reality.
A different measure points in the same direction. The Almanac reports “consistent year-over-year improvement” in mobile Core Web Vitals, “increasing from 36% in 2023 to 44% in 2024, and reaching 48% in 2025” (HTTP Archive Web Almanac, 2025). Less than half of mobile sites pass, so being live and being finished are clearly not the same milestone for most of the web.
One finding in that chapter deserves the attention of anyone planning a build. Home pages pass those checks less often than the pages beneath them: “Secondary pages show higher CWV pass rates than home pages, with a 14% lead on desktop and an 11% lead on mobile” (HTTP Archive Web Almanac, 2025). The likeliest reason is that home pages carry the heaviest hero media and the most third-party scripts, which is worth knowing before you spend the bulk of your build arguing about that one page.
What actually belongs in the weeks after launch:
- Watching what people search for: the first real search data arrives within weeks, and it reliably contradicts at least one assumption. Reading it is covered in how to tell if your website is working.
- Confirming Google has the site: indexing is its own timeline and has nothing to do with build speed, which is why a new website not showing up on Google is a separate problem with a separate fix.
- Fixing what the forms teach you: the first few real enquiries show whether the form asks the right things.
- Adding the pages you now know you need: the ones you could not have known about before the site was live.
- Keeping it current: prices, services and photos drift out of date within a year, which is what ongoing website maintenance is for.
What Has to Be Finished Before Launch Day?
A short list that is non-negotiable, and it is worth asking for explicitly, because “the site is live” and “the site is finished properly” are not the same statement. These are the items that are invisible on screen and expensive to retrofit.
- Every page has a title and a description: written per page, not generated from the business name, because these are what someone reads in search results before deciding to click.
- The site publishes a sitemap and robots rules: the machine-readable list of what exists, and the instructions for crawlers. Both should be live on day one, and the sitemap is the one that earns its keep. Plenty of sites are live today without the other: “The rate of 404 errors for
robots.txtfiles declined to 13% from 14% in 2024” (HTTP Archive Web Almanac, 2025). - Structured data is in place: the business details, the service pages and the FAQ answers marked up so search engines can read them as data rather than as sentences.
- The forms have been tested end-to-end: submitted from a phone, on cellular data, with the notification confirmed as arriving in an inbox somebody checks.
- The site is served over HTTPS: on any current host this is automatic or one click, so there is no excuse for its absence. HTTPS reached “91.7% of desktop pages and 91.5% of mobile pages” in 2025, and the Almanac puts the remaining gap down to “older or low-maintenance sites that have yet to migrate” (HTTP Archive Web Almanac, 2025).
- It loads fast on a phone: this one genuinely is a launch condition rather than a later improvement, because speed comes from decisions made while building and is expensive to retrofit afterwards.
- You have the logins: domain, hosting and profile access in your name, confirmed before launch day rather than discovered missing a year later.
Ask for that list as a checklist you can tick, not as a reassurance. A designer who has done the work will hand it over without hesitating.
What Can You Do to Keep Your Own Build on Schedule?
More than you would think, and most of it happens before anyone writes a line of code. The owner who launches on time is almost always the one who front-loaded the decisions.
- Gather your photos before the project starts: a folder of 20 to 40 real photos of finished work, taken on a phone, is enough. This single step removes the most common delay entirely.
- Write your services out in plain sentences: a paragraph each, in your own words, badly written is fine. Your designer can polish, but cannot invent what you actually do.
- Find your logins now: domain registrar, current host, Google Business Profile. Do it in week one, not launch week.
- Name one decision maker: one person whose feedback is final, even in a business with two owners. This halves revision time more reliably than anything else on this list.
- Give feedback in one pass: collected, specific and in one message, rather than seven messages across two weeks. Feedback arriving in pieces turns one revision round into four.
- Agree the content deadline out loud: in the same conversation as the price, with a date attached.
None of that requires knowing anything about web design. It requires treating the project as something you are participating in rather than something being done to you, which is also the difference between a site that sounds like your business and a site that sounds like a template.
Frequently Asked Questions
How long does it take to build a small business website?
For a straightforward five-to-ten-page local business site, two to three weeks from approved design direction to launch is a realistic window, and it is the lead time published on this site. The building is rarely what fills those weeks. Waiting on photos, service descriptions and decisions is what fills them, which is why the same build can land in two weeks for one owner and drag for three months for another.
What makes a website build take longer than expected?
Content is the usual answer, but the two that catch people out are a second decision maker arriving late and a change of direction after the design was approved, because both restart work that was already finished. Agree who gives final feedback before anything starts, and put a date on your content in the same conversation as the price. Those two habits prevent more delay than any amount of chasing.
Can a website be built in a week?
Yes, if the decisions are already made and the content already exists, because the constraint is almost never how fast someone can write the pages. If you arrive with your services written out, photos of finished work and a clear idea of what the site is for, a small site can move very quickly. If any of those are missing, a one-week target just moves the waiting to a worse place.
How long should I spend on my side of a website project?
Plan for a few hours in total, spread across a few short sessions, with the photo gathering taking most of it. A kickoff conversation, writing out your services, and one or two rounds of feedback is the rest. Projects stall less because the ask is large and more because it sits in an inbox for three weeks.
Is the website finished on launch day?
No, and the useful habit is to book a review about a month after launch, once there is real search data and a few real enquiries to read. That first month reliably turns up a page nobody expected to matter, a form field that is putting people off, or a service worth describing differently. None of that is knowable in advance, which is why a site that never gets revisited slowly stops earning.
Should I wait until my website is perfect before launching it?
No. A site that is live and accurate beats a better site that is still in a folder, because a live site starts being found and starts producing feedback. Launch when the core pages are accurate, the phone number works and the form sends, then improve from there with real information instead of guesses.
Wrapping Up
Two to three weeks is a fair answer for a small local business site, and the version history behind this one shows why that number moves. The building took three days. The waiting, deciding and improving took everything else.
If your build is running late, the useful question is not how fast your designer works. It is which phase the project is sitting in, and whether the thing it is waiting for is on somebody’s list with a date next to it. That is usually a folder of photos and an hour of writing nobody has scheduled.
Worth knowing before you commit to anything: what the work costs is a separate question from how long it takes, and what a website costs in Ontario covers that side. If you want a straight answer about your own site and what web design and development would involve for it, get a free website audit and you will get one.
Further reading: What should you ask a web designer before you hire one? · Website design cost in Ontario: how much should you pay? · How do you replace an old website without losing your rankings?