"Six weeks" is a meaningless answer without knowing what is being built and who is available to answer questions. But projects overrun for a small, repeatable set of reasons, and knowing them lets you plan around them.
Content is the usual bottleneck
Development rarely holds a project up. Waiting for content does. Copy, photographs, product details, staff bios, legal pages — every one of these sits with someone who has a day job, and a site cannot launch around a page nobody has written.
The fix is to start content on day one, in parallel with design, rather than treating it as something to gather once the build is "ready". A page with real text in it also reveals design problems that placeholder text hides.
Decisions have a lead time too
A project moves at the speed of its slowest approval. If a design needs sign-off from three people who meet fortnightly, that is a two-week floor on every revision round regardless of how fast anything is built.
Name one person who can decide. They can consult whoever they like, but the project should never wait on a committee to converge.
Integrations are where estimates break
Anything touching a system you do not control — a payment gateway, an ERP, e-invoicing, a courier API, a legacy database — carries risk that has nothing to do with your site. Documentation is wrong, sandbox credentials take a week, a field means something different than the name suggests.
Ask early which integrations are in scope and get credentials before the work starts, not when the developer reaches that ticket.
Scope changes are fine; untracked ones are not
Changing your mind is normal and usually improves the result. The damage comes from changes absorbed silently, because the schedule stops meaning anything and nobody can see why the date moved.
A realistic shape
For a business site of ordinary size, expect discovery and content in parallel with design, a build phase, then a review and correction period that is longer than people expect — reviews always generate work. The launch itself is the smallest part.
How we approach it
We would rather quote a range and explain what moves it than name a date that ignores the content and approvals sitting outside our control. Where a schedule is tight, we look for what can ship first and what can follow, rather than compressing testing.
If you have a deadline, tell us what it is and we will tell you honestly whether it is achievable. Related reading: choosing between a custom CMS and WordPress.