Two service businesses order what looks like the same website: five pages, one contact form, a service list, some photos. On paper the projects are identical. One is live in a few weeks. The other is still not launched three months later.

Nothing went wrong on the slow one. No one was lazy. The difference was never the page count. It was how many decisions were still unmade at kickoff, how long each draft sat waiting for someone to approve it, and how many parts of the site could only be tested after another system was connected.

So the honest answer to "how long does it take" is a planning rule, not a number: for a focused professional site, think in weeks rather than days, and leave months on the table when the work includes real content production, live integrations, or moving an established site without losing what already works. That is a planning unit. It is not an industry average, and it is not a delivery promise from anyone, including RP.

The useful question is not "how many weeks." It is "what has to be true before this can launch, who owns each of those things, and how long will each one sit in someone's inbox waiting for a yes."

Calendar time is not build time

Most of a website timeline is not spent building. It is spent waiting.

A designer can produce a homepage direction in a day. It can then sit for a week because the owner is busy, or because three partners each want to weigh in, or because the copy it is built around has not been written yet. That week is on the calendar. No one is working. The project is simply blocked.

This is why "it's only about 20 hours of work" and "it'll be ready in two weeks" can both be true and still disappoint you. The hours are the build. The weeks are the build plus every review window, every round of feedback, every wait for an asset, and every dependency that cannot start until an earlier decision is finished. Cutting the price does not shorten the calendar. Removing the waiting does.

That gives the owner a useful lever, and it is not "pay more to go faster." It is: decide faster, approve faster, and get the inputs in on time.

The critical path

The critical path is the longest chain of work that has to finish in order before launch. Some tasks run in parallel; others can't start until an earlier one is done. The length of that unavoidable chain — not the total task list — is what sets the timeline.

For a typical service-business site the chain runs roughly: decide what the site has to do → turn that into pages and paths → produce copy and assets → set the design direction → build and connect the system → migrate anything worth keeping → test the real paths → launch and verify in production.

You can overlap plenty of this. Technical setup can happen while copy is being written. A visual direction can be reviewed before every page exists. Components can be tested before the last page is finished. What you cannot do is finalize a homepage around an offer nobody has approved, map old URLs to destinations that have not been decided, or prove a lead path works before the form, the notification, and the receiving inbox are all connected.

The schedule is governed by those links that can't be skipped or run in parallel. Everything else is noise around them.

Where the time actually goes

Deciding what the site has to do

The first stage is not choosing colors. It is settling the business questions: who the site is for, which services need their own page, which locations genuinely matter, what a qualified visitor should do next, what proof the business can stand behind, and whether this is a new presence, a repair, or a replacement of something that already earns its keep.

If those answers exist, the project moves. If they are still being negotiated, design becomes a very expensive way to hold a strategy meeting. The deliverable here is small and boring — a short written record of the primary buyer, the services being sold, the real service area, the primary action, the proof that can be substantiated, and what an existing site constrains. Every later estimate that skips this contains hidden waiting time.

Turning the business into pages and content

Now the project decides which pages exist, what job each one does, and how a visitor gets from a question to a next step. This is where "a five-page website" stops being a description of anything. A page name is not content. Someone still has to supply the facts, decide what can legally and truthfully be claimed, write the draft, choose the proof, find or shoot the images, confirm the usage rights, and approve the result.

"Client provides content" is the single most common place a timeline quietly dies. It can mean the owner sends finished, approved copy and licensed photos on day one. It can also mean someone forwards a twelve-year-old brochure and three phone photos, and then discovers mid-project that two of the service descriptions are no longer accurate. Neither is wrong. But the schedule has to name which one it is, because they are not the same project.

The fastest way to shorten this stage is not asking everyone to "send content soon." It is handing one person a finite request, a deadline, and a definition of "complete."

Design, build, and the parts a screenshot can't prove

Design should make the service clearer and the next action easier, and it carries its own dependencies: logo files, type and color decisions, photography, and a decision-maker willing to actually choose. "Make it pop" is not an approval criterion; a schedule moves faster when feedback names the business or usability problem a change is meant to solve.

The build turns approved structure, content, and design into working pages — and connects the things a mockup cannot show: forms and validation, where a lead is stored, who gets notified, analytics and consent, structured data, responsive and accessibility behavior, and any booking, payment, CRM, or email integrations the scope includes. Integrations are where estimates go soft, because a second system is involved. Access may be missing. An API may behave differently from its sales page. A notification can send successfully and still land in the wrong inbox. A booking tool can work for one service and fail on another. A responsible estimate separates known configuration from investigation — and if the provider has never actually looked at your current forms, domain account, analytics property, or third-party tools, a precise promise about them is premature.

Accessibility is part of this the whole way through, not a score at the end. W3C's Web Accessibility Initiative recommends evaluating accessibility early and during development, when problems are cheaper to fix, and notes that no automated tool alone can determine whether a site meets accessibility standards — knowledgeable human evaluation is required. Both facts have schedule consequences: it is work spread across the project, and it is work a checker cannot finish for you. (What a checker can and cannot tell you is its own topic — see "What a Website Accessibility Checker Can—and Cannot—Prove.")

Migrating an established site

A brand-new business has no history to protect. An established site may have pages that rank, useful backlinks, analytics continuity, downloadable files, form records, and customers who bookmarked a URL. Migration adds time because the project has to decide what happens to each of those.

Google's site-move guidance is the relevant primary source, and its practical message for a schedule is simple: mapping old URLs to new ones, setting redirects, testing thoroughly, and monitoring the move are all part of the plan, not a launch-night surprise — and Google is explicit that significant changes can cause temporary ranking and traffic fluctuations while pages are recrawled and reindexed, on no fixed timetable. You cannot promise the search dust settles by a certain date, so the monitoring window belongs inside the timeline. The mechanics of doing this safely are a separate article ("How to Redesign a Website Without Losing the Search Visibility You Already Have"); for planning, the point is that a migration and a fresh build should never carry the same estimate. If a proposal gives them the same one, ask what migration work was actually included.

Verifying before you call it done

A site is not finished because the homepage looks right on the builder's laptop. The final review has to exercise the real paths: submit each important form with traceable test data and confirm it was saved, notified, and delivered to the right person; click every phone, email, map, booking, and file link; drive the key tasks by keyboard; check representative mobile and desktop sizes; confirm titles, canonical tags, indexing controls, and redirects from important old URLs; and look at the error and empty states, not just the happy path.

This takes real calendar time because a failure has to be fixed and then re-tested, sometimes more than once. Removing that time from the schedule does not remove the failures; it just moves their discovery from you to your customers. (The full lead-path test is its own procedure — see "How to Test Whether Your Contact Form Is Actually Losing Leads.")

The three projects hiding inside "small-business website"

These are planning shapes, not averages and not RP promises. They exist to show why one phrase covers wildly different timelines.

A focused new site has no history to migrate, one person who can approve, settled services and geography, available content and proof, and a straightforward call or form. Few hard dependencies; plan it in weeks. Its real risks are content readiness, approval delay, and an under-tested lead path.

An established-site rebuild has URLs worth preserving, analytics history, third-party tools, and several stakeholders. Content has to be rewritten or reorganized; forms and tracking have to be replaced without losing continuity. Plan it as a multi-stage project, and leave a longer span — weeks into months — open until inventory, mapping, access, regression testing, and post-launch monitoring are understood.

A connected system — scheduling, payments, CRM handoffs, custom lead records, call tracking, gated content — may have a small visible page count and a large testing surface. The schedule needs access discovery, configuration, failure-state testing, privacy review where it applies, and contingency for systems the provider does not control.

The point is not that one is better. It is that the same three words describe all three, and the estimate should tell you which one you are buying.

"But someone quoted me five business days"

They might be telling the truth. A fixed, fast turnaround is a legitimate product when the scope is genuinely fixed and the inputs are genuinely ready — a template filled with content you have already written and approved can go live quickly, and there is nothing dishonest about that.

The question to ask a fast quote is not "are you lying?" It is "what is deferred to make this fit?" A five-day site usually assumes you supply finished copy and licensed images, that there is no migration, that no integration needs investigation, and that testing is light. Those assumptions may be perfectly fine for your situation. They are worth surfacing before the deadline, not after — because "we'll sort the content out as we go" is the sentence that turns a five-day quote into a five-week reality.

What the owner controls

You cannot make code get written faster by replying to email. You can remove a surprising amount of the waiting. Before kickoff, have ready: one decision-maker with real authority to approve; a current service and location list; the primary customer action; your proof, credentials, reviews, and accurate business details; logo and image files with known usage rights; access to the domain registrar, current site, hosting, analytics, Search Console, and form tools; a short list of who must review and how long each review gets; any legal or industry review you already know is required; and a clear split between must-have-for-launch and nice-to-have-later.

Then protect the project from drive-by feedback. A committee can contribute useful information. It should not produce five conflicting sets of instructions after every review — that is not a design problem, it is a schedule problem wearing a design costume.

A schedule you can actually trust

Ask for a schedule that shows more than a launch date — one that separates the work the provider is doing now, the inputs you owe before the next stage can start, how long each review window stays open and who can close it, and what uncertainty still has to be tested. A plan that names its own dependencies is worth more than a confident date that hides them:

Milestone Owner Starts when Done when
Project decisions Business + provider Kickoff Buyer, services, geography, action, and constraints are written down
Structure Provider Decisions complete Page jobs and conversion paths approved
Content Named writer + approver Structure approved Required copy and assets complete and fact-checked
Design Provider + approver Representative content available System and sample pages approved
Build Provider Design and core content approved Included pages and integrations work in the test environment
Migration Provider + account owners Final destinations settled Every kept asset and old URL has a defined outcome
Verification Provider + business Build complete Tests have evidence; launch blockers are resolved
Launch Named operator Approval complete Live, monitored, and checked again in production

If you need a site live for an event, a lease opening, a seasonal push, or a product launch, say the real deadline before the scope is locked — not after the project starts. Then the sequence that actually works is: state the deadline, inventory the decisions and content and systems and migration risk, define the smallest credible launch scope, assign every dependency to a person, add verification and contingency, and commit to the date only once the critical path is visible.

A schedule that cannot show you what would make it slip has not found the real work yet. So before you ask anyone for a firm date, get your readiness list together and ask to see the critical path — the dependencies, the review windows, and the one input everything else is waiting on. That conversation tells you more than any single number could.

RP's website packages and monthly fees are published, and the offer starts with a free look at your current site. None of that includes a delivery-date guarantee, and you should be wary of anyone who hands you one before they've seen your inputs.

Sources