How Long Does It Take to Build a Website? Timeline and Phases
A realistic website project timeline by site type, the phases from discovery to launch, what causes delays, and how to plan around content and approvals.
A small brochure website typically takes about four to eight weeks from kickoff to launch when the client supplies content on time. A larger business site often takes two to four months, an online store commonly takes two to five months, and custom software can take six months or more. These are planning ranges, not guarantees. The single biggest variable is not the developer's speed but how quickly the client delivers content and decisions. This guide explains each phase, shows a sample schedule and lists what usually causes delays.
Typical durations by project type
| Project type | Illustrative timeline | Main variables |
|---|---|---|
| One-page or very small DIY site | A few days to 2 weeks | Your free time and content readiness |
| Template-based small business site | 3 to 6 weeks | Content delivery, number of revisions |
| Custom brochure site | 6 to 12 weeks | Design rounds, content, approvals |
| Ecommerce store, modest catalog | 8 to 16 weeks | Product data, shipping and tax setup, integrations |
| Custom web application | 4 to 9 months or more | Specification, testing, integrations |
The phases of a website project
Phase 1: Discovery and planning (about 1 to 2 weeks)
The provider learns about your business, goals, audience and requirements. Outputs usually include a sitemap, a list of features and a project plan. This phase is where scope and price are fixed, so rushing it causes trouble later.
Phase 2: Design (about 1 to 4 weeks)
The designer creates the visual direction: layouts for the main pages, typography, colors and imagery. You review and give feedback. The number of revision rounds included in the contract matters here. Consolidated feedback from a single decision maker keeps this phase short.
Phase 3: Content (runs alongside design and build)
Text, photos and product data are written, collected and loaded. This is the phase most likely to cause delay. Providers often start building while content is still arriving, but a site cannot launch with placeholder text.
Phase 4: Development (about 2 to 6 weeks)
Developers turn the approved designs into a working site: pages, forms, mobile layouts, integrations and any custom features. Many providers show progress on a private staging site so you can click around before launch.
Phase 5: Testing and revisions (about 1 to 2 weeks)
The provider checks pages across browsers and phones, tests forms and checkouts, and fixes bugs. You should test too. Check spelling, phone numbers, prices, links and anything else only you would notice.
Phase 6: Launch (a few days)
The site is moved to its live address. Redirects from old pages are put in place if you are replacing an existing site, analytics are connected and search tools are set up. Plan launch for a time when you can respond quickly, rather than the Friday before a holiday.
Phase 7: Post-launch support (about 2 to 4 weeks)
Most providers include a short window for fixing issues. Use it. Real visitors find things testers missed. Schedule a review at 30 and 90 days.
Sample schedule for a 6-page business site
| Week | Activity | Who is responsible |
|---|---|---|
| 1 | Kickoff, goals, sitemap approved | Client and provider |
| 2 | Design concept for home page and one inner page | Provider |
| 3 | Design feedback, revised designs approved; client delivers text for all pages | Client |
| 4 | Development starts; photos delivered | Provider and client |
| 5 | Build continues; staging site available | Provider |
| 6 | Client review; list of changes sent in one document | Client |
| 7 | Fixes, testing, final approval | Provider and client |
| 8 | Launch and follow-up | Provider |
If the client takes an extra two weeks to deliver text in week 3, the entire schedule shifts by two weeks. Providers often cannot reassign the time they reserved, so a delay can also push the project back in their queue.
What causes delays
- Late content. The most common cause by far.
- Slow feedback. Waiting several days for each review adds weeks.
- Too many decision makers. Conflicting opinions create extra rounds.
- Scope creep. New pages or features added mid-project.
- Third-party dependencies. Waiting on a payment processor approval, an account verification or an old vendor to hand over files.
- Provider capacity. A busy freelancer or agency may slip. Ask how they handle this.
- Technical surprises. Old sites with messy data or unusual hosting setups can complicate migrations.
How to keep the project on schedule
- Agree on a dated schedule at the start, with client responsibilities marked.
- Name one decision maker with authority to approve.
- Deliver content before design begins if possible.
- Give feedback in one consolidated document within two or three business days.
- Resist adding features until after launch. Keep a list for phase two.
- Ask for a staging site so you can review as work progresses.
- If launch has a firm deadline, such as a seasonal promotion, tell the provider early and consider a smaller first version.
Worked example: how content delay turns into cost
A provider quotes a 6-week schedule for a site with an illustrative price of $5,500. The client promises content by week 2 but delivers on week 7. The provider has reallocated their time and can restart only after another project finishes, so launch moves from week 6 to week 13. In addition, the provider's contract includes a clause that charges a "restart fee" of $400 after 30 days of inactivity. The client pays $5,900 instead of $5,500, and, more importantly, loses seven weeks of a new site's contribution. If the new site would have produced $1,000 of net benefit per month, the seven-week delay costs roughly $1,600 in missed benefit. These numbers are illustrative, but the pattern is real: delays are rarely free.
Rushing a project
Fast timelines are possible, especially with templates and clear content, but speed has tradeoffs. Rush fees are common, testing is shorter and decisions are made with less reflection. If you need to launch quickly, consider a minimum viable version: fewer pages, a simple design and a clear plan to improve it after launch.
Planning around the calendar
Consider seasonality. If your business is busy in spring, aim to launch in the winter. Avoid launching during peak periods when you cannot monitor orders or inquiries. If you are replacing an existing site with search traffic, launch at a quiet time, and make sure redirects are in place.
When to consult a professional
For regulated industries or when a deadline is tied to a legal or contractual requirement, discuss timing and compliance with an attorney or industry body before you commit to a date.
Frequently asked questions
Can a website be built in a week?
A very simple site from a template can be, particularly if you have your content ready. A custom site cannot be built well in that time.
Why do providers ask for content upfront?
Content shapes layout and length. Designing around placeholder text often leads to rework.
Is a longer timeline a sign of higher quality?
Not necessarily. A realistic schedule matters more than a long one. Ask providers to explain each phase.
What should I do if the project is behind?
Ask for a written update showing what is done, what is late and why. Agree on a revised schedule and, if needed, a reduced scope.
Sources
- U.S. Small Business Administration — project and business planning resources.
- Federal Trade Commission — consumer protection and contract guidance.
- Web Accessibility Initiative (W3C) — accessibility planning for web projects.
