How Long Does It Take to Build a Website? A Practical Guide From Planning to Launch

Most small business websites are planned around four to six weeks from kickoff to launch. A single landing page can be ready in a week or two. A content heavy site with a blog and integrations is usually planned over six to ten. Rebuilding an established site, where existing rankings and old URLs have to survive, commonly takes longer than building something new.

Those are calendar figures, the kind you would mark on a wall planner.

They are much larger than the actual build work, and that gap is the subject of this guide. A site planned over four to six weeks might represent somewhere around forty hours of production — a little over one week at the planning capacity set out in the next section. It is planned over six because of everything that happens around the building.

If you need a date for a launch, a lease, or a season, the useful question is not how fast something can be built. It is what makes a project take six weeks instead of two, and which of those things you control.

The two clocks

Almost every timeline you will read online measures one of two different things, and almost nobody says which.

Build time is production: designing, writing code, loading content, testing. It is the part that gets quoted, and it is usually smaller than people expect.

Calendar time is elapsed time. It is build time plus reviews, approvals, content still being written, the week somebody is away, and waiting on a login to a domain registrar.

Our estimator plans against an assumption of 30 productive hours per week, six hours a day across five days. That is a planning figure used to turn an hours estimate into a rough week range. It is not a staffing promise, a guaranteed capacity, or a commitment to any particular client.

On that basis a small three page site works out at roughly 18 hours. The model does not call that "half a week": it rounds up to the nearest whole week and then shows a band either side, which is how 18 hours becomes one to two weeks of build work. Estimating in whole weeks is deliberate, because nobody schedules half a week of a developer's attention in isolation.

We would not suggest that such a project typically goes live two weeks after you decide to start. It usually does not, and the reason rarely has anything to do with code.

Both numbers can be true at once. They are measuring different things.

This is also why published answers to this question range from under an hour to about a year. Website builder companies quote build time on a template. Agencies quote calendar time on large redesigns. Both are being honest, and they are answering different questions.

How long by website type

Two columns, two clocks.

Build work is generated by our estimator from its own tier and feature hours. Typical calendar figures are planning ranges published by other developers and agencies, cited at the end of this guide. They are not our measurements and not guarantees.

Project	Build work (our model)	Typical calendar (published elsewhere)
One page or landing page	18 hrs	1–2 weeks
Small business site, 4–7 pages	34–49 hrs	4–6 weeks
Content site, 8–10 pages with a blog	62.5–77.5 hrs	6–10 weeks
Ecommerce with a catalogue and checkout	not modelled	6–12 weeks
Logins and membership areas	70–132 hrs	10 weeks+
Redesign of an established site	not modelled	8–12 weeks+

Every build figure above is reproducible in the calculator, and here are the inputs so you can check them rather than take our word for it:

• 18 hrs — one to three pages, template design, content ready, no features.
• 34–49 hrs — five pages; the low end is template design with no features, the high end adds a custom design, SEO setup and analytics.
• 62.5–77.5 hrs — eight pages with a blog, which the model expands to ten because a blog needs an index and a post template; the high end adds custom design, SEO and analytics.
• 70–132 hrs — the low end is membership on an otherwise plain site; the high end is the fully loaded case, ten pages with custom design, full copywriting, membership, payments, a blog, SEO, analytics and a CRM integration.

Memberships and payments are often mentioned in the same breath, and the model disagrees with that. Adding a login area forces a protected section and an account surface, so the model never prices it below 70 hours however simple the rest of the site is. Taking payments is a much smaller piece of work, 43.5 hours in total on an otherwise simple site, which usually lands inside the small business or content site rows rather than deserving one of its own. If someone quotes you the same schedule for both, that is worth asking about.

Two rows say not modelled, and that is the honest answer rather than a gap we have papered over. The calculator has no catalogue, product count or shipping input, so it cannot produce an ecommerce figure and we will not invent one by analogy. A redesign depends almost entirely on the site being replaced — how many URLs, how much content, how many integrations — which is established by an audit, not a form.

Three notes on reading that table.

Page count is the weakest predictor in it. A five page site where every word is already written will generally be ready before a three page site where none of it is.

The one page row is not a typo. Our model treats anything under three pages as a three page build, because a single page still needs the same structure, responsive work, form handling and deployment as a small site. So eighteen hours is the floor the model can produce, not a starting point that drops further for simpler requests.

And ecommerce is its own discipline, where the platform decision drives most of what follows. If that is your project, Commerce 101 covers that decision properly.

A note on rushing

Our model treats rush timing as a real trade. It compresses the estimated schedule by about a quarter and raises the price by about a quarter, because rush work displaces other commitments rather than creating extra hours in the week.

The distinction matters when you compare figures. A larger build of around 132 hours comes out of the model at roughly four to six weeks on standard timing, and roughly three to five weeks rushed. The rushed figure is not the normal one, and quoting it as though it were would understate the schedule by about a week.

Rushing also cannot compress the parts that depend on you.

Where the weeks actually go

A six week project does not contain six weeks of work. Roughly:

• Discovery and structure. Goals, audiences, which pages exist and why.
• Content. Runs alongside everything else and tends to finish last. The largest single variable in most projects.
• Design. Including at least one review round.
• Build. The concentrated production work.
• Testing, launch and handover. Checks, redirects, go live, training.

The parts that stall are rarely the parts that require skill. They are usually the parts that need a decision from somebody who is busy.

A hypothetical six week project

The schedule below is an illustration, not a case study. It is a constructed example built to show how the two clocks relate on a five page small business site with a custom design and content already written, which the model puts at exactly 42 hours of build work. It is not a record of a past project, not an average, and not a schedule we are offering.

Timeline

1. Week 1

   Discovery and structure

   Goals, audiences, the page list and the sitemap. You complete a brief and grant access to the domain, hosting and analytics.

2. Week 2

   Content and design direction

   Copy drafting begins and layout direction is agreed. You supply the logo, photography, services, prices and legal pages.

3. Week 3

   Design

   Key templates are designed and presented. You give one consolidated round of feedback, ideally from one decision maker.

4. Week 4

   Build

   Templates become a working site. Your involvement is lighter here rather than absent: questions still come up, and answering them the same day is what keeps the week on track.

5. Week 5

   Content load and review

   Real copy and images go in and you see the site working. You proofread and sign off on content.

6. Week 6

   Testing, launch and handover

   Accessibility and performance checks, redirects, go live and training. You approve the launch and receive credentials.

Client involvement across a schedule like this is modest in total, perhaps a day or two of real attention spread over six weeks. But when those hours land is what decides the end date.

The same project, stretched to twelve weeks

Also hypothetical, and deliberately so. Same scope, same 42 hours of build work, same people behaving reasonably. Only the waiting is different.

• Plus two weeks. The brief sat unanswered during a busy trading period.
• Plus one week. Photography had not been taken, so a shoot had to be arranged.
• Plus two weeks. Design feedback arrived from three people across eight days, and two of them disagreed.
• Plus one week. Services copy was still being revised while the build was underway.

Nothing went wrong technically. Nobody was unreasonable. The build work was identical. The project simply took twice as long on the calendar.

That is an ordinary outcome rather than a disastrous one, and it is the single best argument for preparing before you start.

What actually causes delay

It is tempting for a developer to write this section as a list of things clients do. That would be dishonest. Delay comes from both sides of the table, and a reasonable project plan accounts for both.

On the client side

• Content that does not exist yet. The most common cause by a wide margin, and the one most often underestimated. Writing good copy about your own business is genuinely hard.
• Feedback from too many people. Three reviewers with conflicting opinions will cost more days than any technical problem.
• No single decision maker. Approval that has to travel upward is approval that waits.
• Access that arrives late. Domain, hosting, analytics and third party accounts are often controlled by somebody who left.

On the developer side

• Scope that was underestimated. A feature that looked small at proposal stage turns out to touch five templates. This is a scoping failure, not a surprise.
• Technical dependencies. A payment provider's approval process, an API whose documentation is wrong, a CMS plugin that does not do what it claims, or a third party service with its own queue.
• Availability. A developer with several projects running has to sequence them, and an overlap can push a week.
• Testing that finds real problems. Good QA sometimes sends work backwards, which is the system functioning correctly rather than failing.
• Migration surprises. On a rebuild, the old site almost always contains something nobody documented.

A developer who presents every delay as a client failing is describing half the picture. Ask how a prospective developer handles the half that belongs to them.

What to prepare before you hire anyone

The highest leverage thing you can do happens before a contract is signed.

• ✓A list of the pages you think you need, and what each one is for
• ✓Your services and prices written down in plain text
• ✓A logo file, and photographs you have the right to use
• ✓Legal pages: privacy, terms, and anything your industry requires
• ✓Login details for your domain, hosting and analytics
• ✓One named decision maker with authority to approve design and copy
• ✓An agreed turnaround for feedback, with three to five business days being a common expectation

The last two matter more than their position on the list suggests, and not because content matters less. Missing content is still the most common single cause of delay, and most of the items above exist to deal with it.

But a content problem is usually solvable once somebody owns it: there is a thing to write, and a person writing it. Contradictory feedback is harder, because it can stall the same decision more than once and nobody experiences it as a delay while it is happening. Naming one decision maker and agreeing a turnaround is what stops that, and it costs nothing.

One point worth being careful about: paying for professional copywriting adds build hours, around 18 in our model, while often removing the dependency that most commonly holds a project up. It can shorten the calendar, but it does not guarantee a shorter project. Copy still needs your review, your corrections and your approval, and a writer still needs source material from you. It moves the bottleneck rather than deleting it.

Redesigns and migrations

Rebuilding an established site is a different job from building a new one, and usually a longer one. Not because the design is harder, but because something already exists that people and search engines depend on.

The additional work is inventory and preservation. Which URLs already earn traffic. What has to be redirected. What the site is quietly wired into. Which content deserves to be carried across and which has simply accumulated.

Skipping that is how a redesign loses rankings that took years to earn.

If you are replacing an existing site rather than starting fresh, Beyond the Redesign covers the audit and migration work this section only summarises.

Launch and handover

Launch is not a button, and in a well run project it is mostly uneventful:

• Cross browser and mobile testing, accessibility checks and performance passes
• Redirects mapped from old URLs to new ones
• Forms tested end to end, including confirming that the email actually arrives
• DNS updated, with propagation allowed for
• Analytics and search tools verified against the live site
• Handover: credentials, a walkthrough, and documentation of how to edit things

Ask early who owns the domain, the hosting and the code after launch. A project that cannot answer that cleanly is one you will have difficulty leaving.

Our website development service page sets out how we scope this stage, and the portfolio shows finished work. Mike's Pro Handyman is a live local service site of roughly the shape described in the small business row above, and ClearWaters Alliance is a demonstration build showing what a content heavy platform looks like when four different kinds of material each need their own structure. Neither page claims a delivery time, because we hold ourselves to the same standard this guide asks of everyone else.

Frequently asked questions

Can a website be built in a week?

For a small site, yes, if every piece of content exists on day one and one person approves decisions quickly. The constraint is readiness far more often than capacity.

How long does it take to design a website?

Design is typically a week or two of a small project's schedule, including a review round. Most of what people experience as "the design taking a long time" is the approval cycle around it rather than the drawing.

Why do agencies quote eight to twelve weeks for something similar?

Usually because they are quoting redesigns of larger sites with more stakeholders. Bigger organisations have more approvals, and approvals are the slowest part of most projects.

Does paying for a rush actually work?

Partly. Our model compresses the schedule by about a quarter and prices it about a quarter higher, because rush work displaces other commitments rather than creating new hours. It cannot compress the parts that depend on your availability.

What is the single biggest cause of delay?

Content that does not exist yet when the project starts.

Can I launch in stages?

Often that is the best answer. A focused first release followed by planned additions gets you live sooner and lets real visitor behaviour inform what comes next.

How long does an ecommerce site take?

Longer than a brochure site of the same page count, because catalogue data, payments, shipping rules and tax handling are each their own piece of work. Commerce 101 covers the platform choice that drives most of the schedule.

---

How this guide differs from our others

This guide answers how long it takes and what moves the date.

How Much Should a Website Cost answers what it costs and how to buy it — scope, tiers and proposals.

Why Your Website Isn't Converting answers what is broken on a site you already have.

Marketing Websites That Actually Convert answers how a strong site should be structured.

Beyond the Redesign answers what replacing an aging site actually involves.

Your next step

If you want figures for your own project, the build calculator runs the model behind every build hour figure in this guide. It estimates production work, so add your own content and approval time on top of whatever it returns.

Sources

Calendar ranges in this guide are typical planning figures published by other developers and agencies. They are cited so you can judge them yourself, and they are not WebCraft Labz measurements.

• Clique Studios, Website Redesign Timeline — redesign ranges by site size, review round expectations, and the observation that projects commonly run over when content and decisions are slow.
• CatesWeb, How Long Does It Take to Build a Website — small business and single page ranges.
• Wix, How long does it take to build a website? — builder and professional ranges, and content identified as the primary delay.
• Tech.co, How Long Does it Take to Build a Website? — build hour comparisons across approaches.
• Oyova, How Long Does It Take to Build an Ecommerce Website? — ecommerce ranges by complexity.

Build hour figures come from the model behind our own build calculator.