For a typical professionally built small-business website, I would plan on roughly four to eight weeks from kickoff to launch.
A small, settled site can move in two to four weeks. A rebuild carrying migration work, integrations, unresolved content, or several approvers can take eight to sixteen weeks or longer.
Here is the planning version I would use:
| Project shape | Useful planning range | Assumptions |
|---|---|---|
| Small, settled site | About 2 to 4 weeks | The offer and page plan are clear, usable copy and photos exist, one person can approve decisions, and the technical setup is straightforward. |
| Typical small-business build or rebuild | About 4 to 8 weeks | Some content and design decisions remain, but the project has a clear owner, normal forms and tracking, and manageable migration work. |
| More involved rebuild | About 8 to 16+ weeks | The old site has important URLs or content to preserve, integrations need coordination, several people approve work, or major business/content decisions are still open. |
Those ranges are deliberately broad. Current 2026 guides from Venbit and Copper Bay Tech use the same basic range: about four to eight weeks for a standard professional small-business site, around two to four weeks for a simpler brochure site, and longer for more involved builds. Venbit and Copper Bay Tech are useful sanity checks, but the actual calendar depends on the project in front of you.
The biggest distinction is elapsed time versus build time. A builder may need only a few focused days for a stage. If the project then waits a week for copy, access, feedback, or approval, the calendar keeps moving.
That is why page count alone is a weak timeline estimate.
Page count is only one input#
Imagine two five-page service-business websites. One has a settled offer, usable copy and photos, one approver, account access, and a straightforward contact form. The other is still deciding how to package its services, has old content and URLs to migrate, depends on an outside system, and needs several people to approve the work.
Both are five-page websites. Their timelines have little in common.
A larger site with clear inputs and repeatable page patterns can even move faster than a smaller site where every page triggers another business decision. If the page plan itself is unsettled, use the service-business page-map test first.
Unresolved decisions are often the biggest delay#
Website work slows down when building has to stop for decisions the business has not made yet: the offer, service structure, homepage message, proof, pricing language, form behavior, inquiry routing, migration choices, or who has final approval.
The slowest part is often not producing the page. It is getting the project to the point where the site has a clear job and the inputs are good enough to build without reopening the same questions.
A fast builder cannot settle an undecided offer by moving the mouse faster.
Production and technical requirements change the build time#
Production methods can make hands-on building and revision faster, but they do not remove the need for planning, review, testing, migration, and launch checks.
The required platform matters too. A business may need to stay on WordPress, Webflow, Squarespace, Wix, or another system because an internal team already supports it or because the existing setup has good reasons to remain. Templates, plugins, permissions, deployment rules, and other platform constraints can change how quickly work moves.
The estimate should reflect the system the website actually has to be built in, not an idealized build process with none of those constraints.
Dependencies and approvals turn build time into calendar time#
An existing site may have old URLs that need redirects, forms connected to another system, analytics, booking tools, advertising tracking, domain settings, or content controlled by another vendor.
The work may be manageable while the dependency is slow. If the domain login is missing, launch waits. If nobody knows which old URLs need to survive, migration waits. If an outside vendor has to change a setting, the website can be ready while the calendar keeps moving.
Review cycles have the same effect. Three focused days of work can occupy several weeks when feedback takes a week, arrives from several people separately, or reopens decisions that were already made.
Projects move faster when access is available early, dependencies are known, one person can give final approval, and feedback arrives in clear rounds.
What helps a website project move faster#
A few things matter disproportionately:
- Settle the core offer and major business decisions.
- Name the person with final approval.
- Gather usable copy, photos, brand material, and account access early.
- Identify forms, integrations, migration needs, and platform requirements before production is far along.
- Respond to real decisions and review rounds promptly.
If you have a hard launch date, work backward from the range that fits the project and leave room for dependencies you do not fully control. A four-week project scheduled against a four-week deadline assumes every input arrives and every decision lands on the first try.
If you are comparing timelines, ask less about how many pages are being built and more about what is still undecided, what dependencies exist, and how quickly the project can make and approve decisions.