Quick answer: A simple brochure site can launch in two to six weeks once content is ready. A custom business site often takes two to four months. Larger catalogue, membership or application-style builds can run four to nine months or more in phases. The calendar slips when scope is unclear, content arrives late, or stakeholders reopen settled decisions. Ask for a phased plan with dependencies, not a single magic number.
“How long?” is the second question after “how much?”. Both need scope before a honest answer.
What “build” includes
People sometimes compare a theme install weekend with a full discovery-to-launch programme. Clarify whether the timeline covers:
- Discovery and sitemap
- UX wireframes and design
- Front-end and CMS build
- Content writing and migration
- Integrations (CRM, payments, booking)
- QA, accessibility checks, redirects
- Training and launch support
A five-day theme tweak is a real deliverable. It is not the same product as a 40-page service site with localisation and gated resources.
Ballpark ranges (assuming responsive stakeholders)
These are planning ranges, not promises:
| Project type | Typical elapsed time |
|---|---|
| Single landing page | 1-3 weeks |
| Small brochure (5-10 pages) | 3-8 weeks |
| Business site with blog and forms | 2-4 months |
| Catalogue / manufacturer style | 3-6 months |
| Ecommerce with clean catalogue | 3-6+ months |
| Custom web application modules | Phased over 4-12+ months |
Elapsed time includes waiting, not only coding hours. A two-week task that waits three weeks for copy still consumes five weeks on the calendar.
Industry-specific builds such as gym website design or manufacturer website design sit in the middle when integrations and catalogue depth appear.
The factors that dominate the schedule
Content readiness. Late text and images are the top delay. Start content inventory on day one.
Decision speed. Weekly feedback loops beat vague “we will review sometime”.
Scope changes. Adding a member portal mid-project resets estimates. Use a change process; a clear web development contract helps.
Integrations. Payment, ERP, CRM and single sign-on add discovery and testing. See also ERP integration style work.
Migration. Redirect maps and legacy URL cleanup take real time.
Compliance. Accessibility targets, privacy notices and security reviews need calendar space.
Staffing. One generalist versus a specialist team changes parallelisation.
A healthy phase breakdown
- Discover (1-3 weeks): goals, audience, sitemap, success metrics
- Design (2-5 weeks): wireframes then visual design for key templates
- Build (3-10+ weeks): templates, CMS, integrations
- Content (overlaps): writing, media, product data
- QA and polish (1-3 weeks): browsers, devices, redirects, speed passes
- Launch and hypercare (1-2 weeks): DNS, monitoring, training
Overlap content with build whenever possible. Serial “design everything, then write everything, then build everything” stretches timelines unnecessarily.
DIY builders versus professional teams
Website builders and page-builder WordPress setups can produce a simple presence quickly if you accept template constraints. Timeline shrinks when you are decisive and supply copy. Timeline expands when you invent brand strategy during colour picking.
Custom teams spend more time on unique templates, performance and integrations. You pay for that with calendar and budget, hopefully in exchange for fit.
Soft launches and phases beat mythical big bangs
Ship a credible v1: primary services, contact paths, analytics. Park secondary languages, niche calculators and the resource library for v1.1. Stakeholders see progress; risk drops. Application migrations often need the same staged mindset as desktop to web application projects.
How to ask agencies for timelines without fuzzy answers
Provide:
- Approximate page inventory
- Must-have integrations
- Who supplies content
- Hard launch constraints (events, campaigns)
- Who approves design and on what cadence
Ask for a Gantt-style outline with your responsibilities marked. If a proposal gives only “six weeks” with no dependencies, dig deeper.
What you can do to go faster
- Freeze sitemap early
- Appoint one decision owner
- Deliver copy in batches by template priority
- Reuse brand assets that already exist
- Limit first-release integrations to the critical path
- Book QA devices and stakeholders in advance
- Avoid parallel rebrands unless scheduled explicitly
Speed without clarity produces rework that is slower overall.
Red flags in timeline conversations
- Guarantees of huge custom scope in a few days
- No line items for content or QA
- “We start coding Monday” with no discovery
- Unlimited revision rounds with a fixed end date
- Ignoring DNS, email and redirect cutover time
Optimistic sales timelines are expensive.
After launch is still part of the timeline
Plan the first month: monitoring, backup verification, small UX fixes, search Console coverage checks, and training refreshers. Teams that book the build to the day of a press event with zero buffer invite public mistakes.
Internal communication during the build
Share a living checklist everyone can see: open questions, content due dates, and blockers. Silence creates duplicate work. A short weekly demo of the staging site keeps executives from inventing parallel requirements in side chats.
Celebrate mid-milestones (design sign-off, first template in CMS, content freeze) so the project feels like progress rather than an endless wait for launch day.
Content freeze and what it means
A content freeze is a date after which page copy for launch templates stops changing except for factual corrections. Without a freeze, designers and developers chase moving targets. Set the freeze realistically, help writers meet it, and park nice-to-have edits for post-launch.
Photographers and product data teams need the same kind of deadline. A site cannot launch on schedule if half the catalogue images are still “coming soon”.
Example calendar for a 12-page business site
Week 1-2 discovery and sitemap, week 2-4 design for home/service/contact, week 3-7 build and CMS assembly overlapping with content writing, week 7-8 QA and redirects, week 8 launch buffer. If content is late by two weeks, the launch moves by two weeks unless you cut page count. Put that dependency in writing at kickoff so nobody is surprised.
Adjust the sample calendar when integrations or migrations are in scope.
FAQ
Can a good website be built in a week?
A simple, template-based presence sometimes can. A distinctive, content-complete business site usually cannot without cutting corners you will revisit.
Why do projects stall at 90%?
Content, legal review, payment credentials and stakeholder availability. Track those dependencies like engineering tasks.
Does using a page builder always mean faster?
It can for layout iteration. It does not remove content, IA or integration work. Poorly managed builders still slip.
How do ongoing retainers relate to build time?
Some work moves post-launch on purpose (extra landing pages, experiments). That is healthy if v1 still meets the launch brief.
Time follows scope and decisions
How long it takes to build a website depends on what you are building and how fast your organisation decides. Use ranges by project type, demand a phased plan, prepare content early and protect the schedule from silent scope growth.
If you want a realistic plan for a new site or rebuild, our web and CMS project work starts with scope and timeline clarity before anyone promises a launch date.
