Most business websites take six to twelve weeks from kickoff to launch. A simple brochure site can be live in two to four weeks. A large multi-location or ecommerce build runs three to six months. The build itself is rarely the bottleneck. Content, feedback and decisions set the calendar, and almost all of those sit on the client side of the table.
That last sentence is the part most agencies will not say out loud during a sales call. It is easier to quote a tidy eight week timeline and let the schedule quietly slip than to explain that the schedule was never really theirs to control. Development work is estimable. Approval is not.
This guide gives realistic ranges by project type, breaks a build into phases with honest durations, and names the specific things that turn an eight week project into a five month one. Treat every number here as typical, not as a promise. Any agency that guarantees a launch date before seeing your content is guessing.
Summary
- Simple brochure site: 2 to 4 weeks
- Standard business site: 6 to 12 weeks
- Service-area or multi-location site: 10 to 16 weeks
- Ecommerce: 12 to 20 weeks
- Custom web app: 4 to 9 months
- Design and development typically account for less than half of the calendar on a standard build
- The three biggest schedule killers are missing content, slow feedback and a stakeholder who appears late
- The fastest projects are not the ones with the biggest teams, they are the ones with one decision maker and content ready before design starts
Table of Contents
- How long does it take to build a website by project type?
- The phase-by-phase breakdown
- Why the client side sets the calendar
- What actually blows up a website timeline
- How to genuinely go faster
- Common mistakes
- The bottom line
- Frequently asked questions
How Long Does It Take to Build a Website by Project Type?
Six to twelve weeks covers the majority of business websites. The spread inside that range comes from page count, how many integrations are involved, and how many people have to sign off. Here is how the common project types actually behave.
| Project type | Typical timeline | What drives the range |
|---|---|---|
| Simple brochure site (3 to 6 pages) | 2 to 4 weeks | Template-led, minimal content, one decision maker |
| Standard business site (8 to 20 pages) | 6 to 12 weeks | Custom design, real copywriting, basic integrations |
| Service-area or multi-location site | 10 to 16 weeks | Location page architecture, local SEO structure, duplicate content control |
| Ecommerce (up to a few hundred products) | 12 to 20 weeks | Catalogue data, payments, tax, shipping rules, fulfilment |
| Custom web app or portal | 4 to 9 months | Authentication, database design, permissions, testing cycles |
| Redesign of an existing site | 8 to 14 weeks | Migration, URL mapping, preserving rankings |
Those are working ranges based on how projects run in practice, not measured research. Read the low end as what happens when a client is organised, decisive and has content ready. Read the high end as what happens when they are not.
Why does the same brief produce different timelines at different agencies?
Mostly because agencies define the word “website” differently. One shop quotes four weeks and means a theme installed, populated with the client’s own copy, and pushed live. Another quotes twelve and means research, custom design, written content, structured data, analytics, accessibility review and a migration plan. Both are being honest. They are selling different products.
Before you compare two timelines, compare what is actually inside them. Our website packages spell out scope by tier for exactly this reason. A timeline without a scope attached is a marketing number.
Does a bigger team make it faster?
Rarely, and past a point it makes things slower. Website work has a lot of sequential dependencies. Design cannot finalise until structure is settled. Build cannot finish until design is approved. Adding people to a queue does not shorten the queue. It adds coordination overhead and more opinions to reconcile.
The projects that finish early almost never have more people on them. They have fewer.
The Phase-by-Phase Breakdown: Where the Weeks Actually Go
A standard business site broken into phases looks like this. Durations assume a responsive client. Every phase has a work component and a wait component, and the wait component is the one nobody budgets for.
| Phase | Typical duration | Who controls it | What stalls it |
|---|---|---|---|
| Discovery and requirements | 3 to 7 days | Shared | Scheduling the kickoff, unclear goals |
| Information architecture and sitemap | 3 to 5 days | Agency, client approves | Internal debate about navigation |
| Wireframes and structure sign-off | 1 week | Client approval | Reviewers who want to see colour before approving layout |
| Content and copywriting | 2 to 6 weeks | Mostly client | Nobody was assigned to write it |
| Visual design | 2 to 3 weeks | Agency, client approves | Subjective feedback with no decision maker |
| Development and build | 2 to 4 weeks | Agency | Design changes arriving mid-build |
| Integrations and third parties | 1 to 3 weeks | Shared and external | API access, vendor approval queues |
| QA, accessibility and performance | 1 to 2 weeks | Agency | Late content still arriving |
| Launch and migration | 1 to 3 days | Shared | DNS access, hosting credentials, redirect mapping |
Add the agency-controlled rows together on a standard build and you land somewhere around five to nine weeks of actual production work. Add the client-controlled and shared rows and you can easily add another four to eight. That is the whole thesis of this article in one arithmetic exercise.
Discovery is short but it is load-bearing
Discovery rarely takes more than a week, and skipping it never saves that week. It relocates it to month three, when someone realises the site was designed for the wrong audience or the wrong buying process. A short, structured discovery phase is one of the cheapest schedule protections available.
Content is the phase that silently doubles
Two to six weeks is a wide band because content behaves differently depending on who owns it. When an agency writes it, it is a scheduled task with a due date. When the client writes it, it becomes the thing they do after the day job, which means evenings, weekends and eventually nothing at all.
Design and build can run partially in parallel with content, but only up to a point. Real copy changes layout. A hero written to two lines and a hero written to seven are not the same design problem. Building against placeholder text and swapping in real copy at the end reliably produces a rework cycle nobody planned for.
Why the Client Side Sets the Calendar, Not the Build
Development time is the most predictable part of a website project. A competent team knows roughly how long a template takes, how long a custom component takes, how long a checkout flow takes. Those estimates are usually close.
What is not predictable is how long a design sits in someone’s inbox. Four things on the client side move the calendar more than anything an agency does.
1. Feedback latency
This is the single most underestimated variable in web projects. A build with six approval gates and a two day turnaround on each loses under two weeks to review. The same build with a seven day turnaround loses six weeks. Nothing about the work changed. Only the response time did, and it more than tripled the review cost.
Most clients think of feedback as free because it is not billed. On the calendar it is one of the most expensive line items in the project.
2. Stakeholder count
Every additional reviewer adds a round trip and a chance of contradictory direction. Two people can resolve a disagreement in a message. Five need a meeting, and the meeting needs a date everyone can make. The scheduling cost alone can add a week per approval gate.
Worse is the stakeholder who appears late. A director who was not in discovery and not in design review, who sees the site for the first time in staging, will produce feedback that is structural rather than cosmetic. That is not a revision, it is a partial restart.
3. Content readiness
Photography that does not exist yet. Bios from eleven team members. Case studies legal has not cleared. Product descriptions that live in a spreadsheet nobody has updated since 2023. None of it is a development problem, and all of it stops a launch.
4. Decision authority
Ask one question at kickoff: who can approve without checking with anyone else? If the answer is unclear, or if it is “the team”, add weeks to the estimate. Projects with a single accountable decision maker finish faster than projects with a committee, every time, without exception.
What Actually Blows Up a Website Timeline
Below are the recurring causes of overrun. None of them are exotic. All of them are predictable, which means all of them are preventable.
Content that was never really started
The most common single cause. Design finishes, build finishes, and the project sits waiting for the About page. Weeks pass. If you are writing your own copy, treat it as a project task with an owner and a date, not as something that will happen naturally.
Scope changes arriving mid-build
A booking system added in week six is not the same request it would have been in week one. It touches architecture, design, testing and sometimes hosting. Late additions cost more than their own build time because they invalidate work already completed.
Third party integrations and approval queues
Payment processors, booking engines, CRMs, MLS feeds, insurance quoting tools and property management systems all have their own timelines. Some require account verification. Some require a review before granting production API credentials. That queue belongs to the vendor, and no amount of project management shortens it. Start integration requests in week one, not week six.
Migration surprises
Redesigns hide their difficulty. A site with 40 visible pages might have 400 indexed URLs once old blog posts, tag archives, PDFs and legacy landing pages are counted. Every one of those needs a redirect decision. Skipping that step is the standard way to lose rankings at launch, which is why redesigning without losing SEO traffic is its own discipline rather than a launch day checkbox.
Access nobody can find
DNS controlled by a developer who left in 2019. A registrar account tied to a personal email that no longer exists. Hosting owned by a relative who set it up as a favour. This is a genuinely common way to lose a week at the very end of a project, and it is entirely avoidable by confirming access during discovery instead of on launch day.
Accessibility treated as a final check
Colour contrast, focus states, heading order and form labels are cheap to build in and expensive to retrofit. Discovering a contrast failure across an entire palette in QA week means revisiting the design system, not editing a stylesheet. Canadian organisations have specific obligations here, covered in our guide to website accessibility compliance in Canada.
How to Actually Go Faster
Speeding up a website project is mostly about removing waiting, not adding effort. These are the levers that work, roughly in order of impact.
- Have content ready before design starts. Not perfect, not final, but written. Real words in a document beat a promise of words later. This alone can cut two to four weeks from a standard build.
- Name one decision maker. One person who can approve without escalating. Others can advise, but one person signs.
- Agree a feedback SLA at kickoff. Forty eight hours on every review round, written into the schedule. Then hold both sides to it.
- Get every stakeholder into the first review, not the last. If a senior person will have opinions, extract them at wireframe stage when changes are cheap.
- Consolidate feedback into one document. Six people sending separate emails produces contradictions the agency has to resolve, and resolving them takes another round trip.
- Confirm access in week one. Domain registrar, DNS, hosting, analytics, ad accounts, any integration credentials. Test the logins, do not just locate them.
- Start integration requests immediately. Vendor approval queues run on their clock and can be worked in parallel with everything else.
- Approve structure before visuals. Sign off the wireframe as a layout decision. Do not wait for colour to decide whether a page order makes sense.
- Freeze scope at build start. Keep a list of good ideas for phase two rather than absorbing them mid-project.
- Book the launch window early. A target date with a stakeholder calendar attached creates a forcing function that a vague “when it is ready” never will.
Notice that eight of those ten are client-side actions. That is not deflection, it is where the leverage genuinely sits. An agency can compress its own production time by maybe twenty percent through good process. A client who responds in two days instead of ten can compress the total calendar by half.
What about templates and page builders?
Templates genuinely save time, mostly in design and front-end build. They do not save content time, review time or integration time, which is why a templated site with a slow client still takes months. Use a template to shorten the phase that is already short, and understand that it does nothing to the phases that are long.
There is also a quality trade. Templates constrain what you can express visually, and heavily customised templates often end up slower to build than a clean custom front end. If brand differentiation matters to the business, our design packages handle that layer properly rather than fighting a theme.
Should you launch in phases?
Usually yes. Launching a solid core site in eight weeks and adding the booking system, the resource library and the client portal over the following quarter is almost always better than waiting five months for everything at once. A live site earns its keep while phase two is being built. A staging site earns nothing.
Phased launches also surface real user behaviour before you commit budget to features you assumed people wanted.
Common Mistakes
- Choosing an agency on quoted timeline alone. The shortest quote usually means the smallest scope, not the fastest team. Compare deliverables before dates.
- Assuming content will sort itself out. It will not. Assign it, date it, or pay someone to write it.
- Reviewing design without the decision maker present. Approval that gets overturned later is worse than no approval at all.
- Sending feedback as a stream of one-line messages. Batch it. Consolidated feedback is a single round trip, scattered feedback is many.
- Adding scope while calling it a small tweak. Multilingual support, a members area, a booking flow, none of these are tweaks.
- Leaving DNS and hosting access until launch week. The most avoidable delay in the entire process.
- Treating QA and accessibility as buffer time. They are real work with real durations, not compressible padding.
- Planning a launch for the Friday before a holiday. If anything breaks, nobody is available to fix it. Launch mid-week, mid-morning.
- Expecting the timeline to survive a mid-project rebrand. If brand work is likely, do it first or accept the restart.
Almost every item on that list costs days or weeks, and almost every one is free to avoid. That asymmetry is the reason a well-run project can beat a better-funded one.
The Bottom Line
Six to twelve weeks is the honest answer for most business websites. Two to four weeks for something simple. Three to six months for ecommerce or anything with real complexity behind it. Those ranges hold reasonably well across the industry because the work itself is well understood.
Where projects diverge is everything around the work. The site that launches in eight weeks and the site that launches in five months are frequently the same brief, given to the same team, with the same budget. The difference is that one client had content ready, one approver, and a two day feedback habit, and the other had none of the three.
So when you ask an agency how long a website takes, ask a better second question: what do you need from us, and by when? A team that answers that precisely is a team that has run this before. A team that says “just leave it with us” is a team you will be chasing in month four.
Cost and timeline are the same conversation from two angles, and both are set by scope. If you are still sizing the project, the Canadian digital agency pricing guide covers the budget side of the same question.
Frequently Asked Questions
How long does it take to build a simple website?
Two to four weeks for a three to six page brochure site, assuming the content is written and one person is approving. That timeline usually means a refined template, a light design pass and standard integrations like a contact form and analytics. If the content is not ready, the same site takes six to ten weeks, and the extra time is entirely waiting.
Why do web design projects take longer than quoted?
Because most quoted timelines measure production days and assume immediate approvals, while real projects run on calendar days that include review waits, content delays and scope additions. A quote of eight weeks often means eight weeks of work if nothing waits on anyone. Add a week of feedback latency per approval gate and a content phase nobody staffed, and twelve to sixteen weeks is the realistic result.
How long does an ecommerce site take to build?
Twelve to twenty weeks is typical for a catalogue up to a few hundred products. The design and build are not what stretches it. Product data, images, variant structures, tax and shipping rules, payment gateway approval and fulfilment integration all add time, and most of those depend on data the client owns or a third party controls. Large catalogues and complex logistics push well past twenty weeks.
Can a website be built in a week?
Yes, under specific conditions: a single-page or very small site, a template with minimal customisation, content that already exists, one decision maker available daily, and no third party integrations. It is a real option for a launch page or a simple service site. It is not a compressed version of a full business website, it is a different product, and it should be judged as one.
Should I wait until my content is finished before hiring an agency?
No. Start the conversation early, because discovery and structure work will change what content you actually need. Waiting for perfect content before engaging usually means writing pages that get cut. Start the project, agree the sitemap, then write content against a structure that has already been decided.
Get a Realistic Timeline for Your Build
If you want a schedule built around your actual scope rather than a generic estimate, look at our website packages or the full range of Wise Media services, then start an intake and we will map the phases, the approval gates and what we need from you to hit them.