Skip to main content
Web Development
August 14, 20267 min read

How Long Does It Take to Build a Website?

A small business site takes 4–6 weeks from kickoff, e-commerce 8–12. Why projects run late, and four things that keep yours on schedule.

Muhammad Mubashar Shahzad

Founder & lead developer at WebDevStudio — React, TypeScript and MERN

How Long Does It Take to Build a Website?

From kickoff, a small business marketing site typically takes 4–6 weeks. E-commerce and integration-heavy builds run 8–12 weeks, and custom applications 3–6 months. The most common cause of overrun isn't development — it's waiting on the client's content, feedback and approvals. A timeline that doesn't name your obligations as well as the developer's will be missed.

"From kickoff" is doing real work in that sentence. Kickoff is the day the developer has what they need to start, which is often weeks after the day you signed. If you're still choosing who to hire, how to hire a web developer when you don't know how to code comes first.

Been quoted a timeline you're unsure about? Tell me the scope and what you already have ready, and I'll tell you whether it's realistic — free, before you commit. If the timeline is fine, I'll say so. Get in touch.

Typical timelines by project type

ProjectFrom kickoffWhat usually sets the pace
Landing page / one-pager1–2 weeksHow fast the copy is ready
Small business site, 5–8 pages4–6 weeksContent for every page, plus two review rounds
Larger marketing site, 10–15 pages6–10 weeksContent volume and the number of approvers
E-commerce8–12 weeksProduct data, images, payment and shipping setup
Integration-heavy build8–12 weeksThe other system's API, and access to a test account
Custom web application3–6 monthsUser roles, permissions and the number of workflows

These are working ranges for a competent solo developer or small studio, and they assume you're responsive. They stretch when approvals involve a committee, and they compress only slightly when you throw money at them — most web work doesn't parallelise as neatly as people hope.

What actually happens in each phase

  • Discovery and scope (3–7 days). Turning what you want into something specific enough to build and price. Skipping this is how projects end up in change requests.
  • Design (1–2 weeks). Layouts and a visual direction, then a review round. Longer if it's a fully custom design rather than a design system applied to your brand.
  • Build (2–4 weeks for a marketing site). The part people imagine is the whole project. It's usually less than half of it.
  • Content population. Almost always the bottleneck — see below.
  • Testing and fixes (3–5 days). Browsers, devices, forms, and the things that only break with real content in them.
  • Launch and handover (1–3 days). DNS, redirects from the old URLs, analytics, and a walkthrough so you can run it.

Note how much of that list isn't coding. When a quote's timeline looks short, the usual explanation is that it counted only the build phase — which is why timeline belongs in the quote as a line item with your obligations attached, per what should be in a web development quote.

Why projects run late — and why it's usually not the developer

This isn't a complaint about clients. It's a structural feature of web projects, and knowing it in advance is the thing that prevents it.

Content is the number one cause. Writing twelve pages of copy about your own business is genuinely hard, it's nobody's actual job, and it always takes longer than the week everyone assumed. Meanwhile the build is finished and waiting, which is why a project can be "almost done" for a month.

Feedback rounds are the second. A review that sits for ten days doesn't cost ten days — it often costs more, because the developer has moved to another project and has to pick yours back up.

Approvals are the third. One decision-maker is fast. Three people who must agree, one of whom is on leave, is a fortnight nobody scheduled.

What you have to supply, and by when

WhatWhen it's neededCost of being late
Final copy for every pageBefore build starts, ideallyThe single biggest source of delay
Logo files, fonts, brand coloursBefore design startsDesign work gets redone
Photos, or a decision to buy stockBefore content populationPages sit half-finished
Domain and hosting accessBefore launch weekLaunch slips regardless of readiness
Consolidated feedback per roundWithin 2–3 business daysCompounds — the developer context-switches away
A named decision-makerDay oneEvery round takes as long as the slowest approver

The full pre-kickoff list is in what to give a web developer before starting.

Two timeline red flags

A timeline that doesn't name your obligations. If the schedule lists only the developer's milestones, it will be missed, and the conversation about whose fault that was will be unpleasant. A schedule with your deadlines in it is a sign of someone who has run projects rather than just sold them.

"Two weeks" for a custom build. Either it's a template being sold as custom, or discovery, testing and handover have been quietly left out of the count. Ask what happens in each week — the answer resolves it immediately.

How to keep the project on schedule

  • Write the content before the build starts, not during it. If you can't, say so up front so the schedule reflects reality instead of hope — and consider paying for copywriting, which is cheaper than a two-month stall.
  • Name one decision-maker with authority to approve. Gather other people's opinions before the round, not during it.
  • Consolidate feedback into one document per round. Ten separate emails over a week is a week, not ten minutes.
  • Book the review slots in advance, in your calendar, at kickoff. The rounds you scheduled are the ones that happen on time.

When you don't need to hire anyone

If your honest answer to "when will the content be ready?" is "I have no idea", then the fastest route to a live site may not be hiring a developer at all — it may be a site builder you fill in yourself over a few evenings. A developer can't move faster than your content, and paying someone to wait is the most expensive way to be slow.

What I'd recommend

Add two weeks to whatever timeline you're given, and spend them on content before the project starts rather than during it. Projects that begin with the copy written finish roughly on schedule; projects that begin with "we'll sort the content as we go" do not.

And treat any timeline that doesn't ask anything of you as a warning rather than a convenience.

Frequently asked questions

How long does it take to build a small business website?

Typically 4–6 weeks from kickoff for a 5–8 page site, assuming the content is ready and feedback comes back within a few days. Larger 10–15 page marketing sites run 6–10 weeks, e-commerce and integration-heavy builds 8–12 weeks, and custom applications 3–6 months. Kickoff means the day the developer has what they need — often weeks after you signed.

Why do website projects take longer than quoted?

Almost always because of content, feedback and approvals rather than development. Writing pages of copy about your own business is harder than it sounds and is nobody's actual job, so the build finishes and waits. Slow review rounds compound the delay, because the developer context-switches to other work and has to pick yours back up.

Is two weeks realistic for a custom website?

Rarely. Two weeks usually means either a purchased template being presented as custom work, or a count that excludes discovery, testing, launch and handover. Ask what happens in each week — a developer who has actually run projects will walk you through discovery, design, build, content, testing and launch without hesitating.

What makes a website project finish on time?

Content written before the build starts, one named decision-maker with authority to approve, feedback consolidated into a single document per round, and review slots booked into calendars at kickoff. Those four things matter more than any scheduling technique the developer uses, because they remove the bottleneck that causes most overruns.

Can I speed up a website build by paying more?

Only slightly, and less than people expect. Web projects don't parallelise cleanly — adding people to design and build creates coordination work, and none of it removes the real constraint, which is usually your content and approvals. Paying for copywriting genuinely does speed things up, because it attacks the actual bottleneck.

Where to start

Before you agree a date, answer one question honestly: when will the final copy for every page exist? That date, not the developer's capacity, is what sets your launch.

If you'd like a realistic timeline for your scope, describe it and I'll give you one — including the parts that depend on you. Get in touch, or see what I build.

Web Development
Small Business
Hiring a Developer

Interested in working together on a React or MERN project?

Get in Touch