How Long Does It Take to Build a Business Website?

Realistic ranges by project type

These are working ranges from kickoff to launch, assuming a competent team and a client who responds within a few days:

• Brochure site, 5–10 pages — 4 to 8 weeks.
• Mid-size marketing site with a CMS — 8 to 14 weeks.
• E-commerce — 3 to 6 months, driven more by product data than code.
• Anything with accounts, payments or integrations — 3 to 6 months minimum.
• Custom web application — 6 months and up; the range stops being meaningful because scope dominates.

If a quote sits far below these, look at what has been excluded. Usually it is discovery, testing, content population or post-launch support — work that still has to happen, just later and often at your expense.

Development is rarely the bottleneck

People assume the schedule is set by how fast someone writes code. On most business websites the build is a minority of elapsed time. The rest is decisions, approvals and waiting.

A typical eight-week brochure project might be one week of discovery, two of design including revisions, two of build, one of content population, one of testing and fixes, and one of launch preparation. Only two of the eight are development. Doubling the size of the dev team compresses those two weeks and nothing else.

The three delays that cause most overruns

Nearly every late project traces to one of these, and all three sit on the client side:

• Content that does not exist. The most common cause by a distance. Design and build can start on placeholder text, but nothing launches on it. Projects routinely sit finished for weeks waiting for page copy, product descriptions or staff photos.
• Slow or fragmented feedback. A round of review that takes two days keeps the schedule. One that takes two weeks because four stakeholders must agree adds a fortnight per round — and there are usually three or four rounds.
• Missing third-party access. Domain registrar logins, hosting, payment gateway, analytics, the CRM. These are always needed and almost never ready, and tracking down who holds a credential at a company someone left two years ago can take weeks.

A good agency asks for all three during discovery precisely because they are the schedule. Our note on why upfront discovery saves money covers what that session should extract.

What legitimately compresses a timeline

• Write the content first. Copy ready at kickoff can remove weeks. It is the single highest-leverage thing a client controls.
• Name one decision-maker. One person who can approve without convening a committee. Design by consensus is the most reliable way to add a month.
• Gather credentials during discovery, not the week before launch.
• Use a proven theme or design system where brand differentiation is not the point. A bespoke design is worth it for some businesses and pure schedule cost for others.
• Cut scope, not quality. Launch with three templates instead of nine and add the rest later. Phasing is nearly always better than compressing.

What does not work

Two shortcuts consistently backfire. Skipping discovery to “get started sooner” means building the wrong thing and rebuilding it, which costs more than the week it saved. Compressing testing moves defects from staging to production, where your customers find them and fixing them is more expensive and more embarrassing.

Adding developers to a late project rarely helps either. Coordination overhead grows, and on a website the constraint is usually approvals rather than hands.

How to read a proposed schedule

When you receive a timeline, check four things:

• Does it name the dates you must hit — content delivery, feedback windows, credential handover? A schedule with no client obligations is not a schedule.
• How many review rounds are included, and what happens on the next one?
• Is testing a distinct phase with real duration, or a day tacked on the end?
• Is there contingency? A plan with zero slack is a plan that will slip.

A timeline that names your obligations is a good sign. It means the agency has been late before for the usual reasons and has decided to be explicit about them.

Launch is not the end

Budget for the fortnight after go-live. Real traffic surfaces things staging never does: an edge-case checkout failure, a form not reaching the right inbox, a layout breaking on a device nobody tested. Agencies that treat launch day as the finish line leave you to discover those alone — check what post-launch support is included before you sign.

For the wider decision about who builds it, see choosing a development partner, or our custom software work.