Website Development Timeline (with Template)
Website Development Timeline (with Template)
A realistic website development timeline by phase: discovery, content, design, build, QA, launch and hypercare, with what makes projects slip and a template.
A realistic website development timeline for a business site of moderate size, roughly twenty to sixty pages built from four to eight templates, runs about ten to twenty weeks from kickoff to launch, followed by a hypercare period. A small template-based site can take four to eight weeks; a large multilingual or integrated site can take six months or more. These are typical industry durations, not commitments for any particular project. The phases are the same at every size: discovery, content and structure, design, build, QA, launch and hypercare.

What changes the length is rarely the code. It is content, decisions and integrations, and the second half of this guide is about those.
Website development timeline: phases and typical durations
The durations below assume a mid-size site, a vendor working with a client contact who can make decisions, and content that is partly written. Phases overlap: content runs alongside design, and build starts on approved templates before the last one is designed.
| Phase | What happens | Typical duration | Exit gate |
|---|---|---|---|
| 1. Discovery | Goals, audience, analytics review, page inventory, integrations list, platform decision, success measures | 1 to 2 weeks | Signed scope and schedule |
| 2. Content and structure | Sitemap, URL plan, page outlines, keyword mapping, content assignments, redirect map if replacing a site | 2 to 4 weeks, continuing alongside design | Approved sitemap; content schedule with owners |
| 3. Design | Wireframes for key templates, visual design, component library, mobile and desktop reviews | 2 to 5 weeks | Approved designs for all templates |
| 4. Build | Theme or front end, CMS setup, templates, integrations, forms, analytics, content entry | 3 to 8 weeks | Staging site complete with final content |
| 5. QA | Browser and device testing, accessibility and performance audits, forms and integration tests, redirect validation, client review | 1 to 2 weeks | Issue list closed; client sign-off |
| 6. Launch | DNS and TLS, redirects live, sitemap submitted, analytics verified, monitoring on | A few days, at a time you choose | Site live; launch checks passed |
| 7. Hypercare | Crawl errors, rankings, forms and performance watched; fixes; editor training | About 30 days | Handover to maintenance |
Each phase has an exit gate for a reason. Starting design before the sitemap is approved, or build before designs are approved, is how a project ends up redoing work. The gates are where the timeline is protected, not where it is lost.
How size changes the numbers
- Small site (up to ten pages, a purchased or lightly customized theme, content ready): four to eight weeks, with discovery and design compressed into one or two weeks each.
- Mid-size site (twenty to sixty pages, custom design, a few integrations): ten to twenty weeks.
- Large or complex site (multilingual, headless, single sign-on, extensive migration, several stakeholders): six months or more, often delivered in releases.
- Web application or portal: scheduled as software, in sprints, rather than as a site. The phases above still apply to the public pages.
What slips timelines
Ask anyone who has delivered a hundred websites what delayed them, and the list is short and repetitive.
- Content arriving late. The single biggest cause. Pages cannot be built, reviewed or tested without final copy, and placeholder text hides layout problems until the last week. Fix: assign every page an owner and a due date in discovery, and start writing before design finishes.
- Slow decisions. A design review that takes three weeks instead of three days adds three weeks. Fix: name one decision maker, agree a turnaround for reviews, and put the review dates in the schedule.
- New stakeholders. Someone sees the designs late and reopens settled questions. Fix: identify everyone who can say no during discovery and show them the wireframes, not only the final designs.
- Scope growth. “While we are at it” features. Fix: a written scope, a change process with a visible cost and schedule effect, and a version-two list for good ideas.
- Access and accounts. Hosting, DNS, analytics, CRM and API access requested in week eight instead of week one. Fix: an access checklist completed during discovery.
- Integrations. The CRM has no sandbox, the booking tool’s API behaves differently from its documentation, the payment account needs verification. Fix: prove each integration on staging early, before it is on the critical path.
- Migration surprises. Old content in odd formats, broken media, thousands of URLs nobody listed. Fix: crawl the current site in discovery and size the migration from the crawl, not from memory.
- Brand and legal approval. Logo usage, claims, privacy text and accessibility statements that need sign-off from people outside the project. Fix: schedule those reviews as tasks with dates.
- QA findings treated as optional. Issues found in testing need time to fix and retest. Fix: hold the QA phase at its planned length instead of launching on the planned date regardless.
- Launch timing. Launching before a holiday, a campaign or a conference with no one available afterward. Fix: launch early in a quiet week with the team on hand for hypercare.
Timelines and budgets slip together, because every week of delay is paid for in meetings and rework. The drivers behind cost are covered in our website development cost guide.
Template: a week-by-week website project timeline
Copy this website development timeline template into a spreadsheet or project tool and adjust the weeks to your scope. “You” means the client team; “Vendor” means the agency or developer. Replace the sixteen-week frame with your own, but keep the gates and the owner column, because those are what make the plan enforceable.
Week Phase Activities Owner Gate / deliverable
---- --------------------- ------------------------------------------------ ----------- ---------------------------------
1 Discovery Kickoff, goals, audience, analytics review Both Access checklist completed
2 Discovery Page inventory, integrations, platform decision Vendor Scope and schedule signed
3 Content and structure Sitemap, URL plan, redirect map (if replacing) Vendor Sitemap approved
3-4 Content and structure Page outlines, keyword map, content assignments Both Content schedule with owners
4-5 Design Wireframes for key templates Vendor Wireframes approved
5-8 Design Visual design, component library, mobile review Vendor All templates approved
4-10 Content (parallel) Writing, editing, photography, migration prep You Final copy delivered per schedule
8-12 Build Theme/front end, CMS, templates, integrations Vendor Templates built on staging
11-13 Build Content entry, forms, analytics, search, SEO tags Both Staging complete with final content
13-14 QA Browser/device, accessibility, performance, Vendor Issue list closed
forms, integrations, redirect validation
14 QA Client review and sign-off You Launch approved
15 Launch DNS, TLS, redirects, sitemap, analytics checks Vendor Site live, launch checks passed
15-19 Hypercare Monitoring, fixes, editor training Vendor Handover to maintenance plan
Three rules make the template work. First, the content row is on the critical path, so give it dates and names rather than a note that says “ongoing”. Second, each gate needs a named approver and a turnaround, for example three working days. Third, keep a change log: every addition goes on it with its effect on the schedule, so the launch date moves for reasons everyone can see.
If you are replacing an existing site rather than starting from nothing, add the audit and redirect steps from our website redesign checklist to weeks one through three and to launch day.
Where PS3G fits
PS3G builds websites on WordPress, .NET and modern JavaScript stacks for organizations of every size, with a US team in Wilmington, Delaware and a delivery center in India. Every proposal includes a phase-by-phase schedule like the template above, with the dates that depend on your reviews and content marked clearly, and the content plan is written in discovery so it never becomes the thing that delays launch. Our website development services page explains the process, the platforms we work with and how an engagement starts, with a first conversation, a short assessment and a written proposal.
Related reading
- Website Development Cost: What Drives It and How to Budget
- Website Redesign Checklist: 40 Steps That Protect Your Rankings
- Website development services
Frequently asked questions
How long does it take to build a website?
As a typical industry range, four to eight weeks for a small template-based site with content ready, ten to twenty weeks for a mid-size custom site with a few integrations, and six months or more for a large multilingual or integrated site. The code is rarely the long pole; content, decisions and integrations are. A schedule with named owners and review turnarounds is the best predictor of hitting the date.
Can a website be built in two weeks?
A small site on a purchased theme with content already written, one decision maker and no integrations can be launched in about two weeks. Anything with custom design, content still to be written, a migration or a CRM connection cannot be done well in that time. If a date is fixed, reduce the scope to what fits and plan a second release rather than compressing QA.
Which phase takes the longest?
Build usually has the longest planned duration, but content most often takes the longest in practice because it runs in parallel and depends on people outside the project team. Design reviews are the second most common delay. Plan content from week one with owners and dates, and treat review turnaround as a scheduled task rather than an assumption.
How can we shorten a website development timeline?
Have content written or assigned before kickoff, name one decision maker with a review turnaround of a few days, limit the number of templates, reuse an existing design system or brand kit, prove integrations early on staging, and defer nice-to-have features to a second release. Compressing QA or hypercare saves days and costs weeks later.
Does a redesign take longer than a new website?
Often, yes, because a redesign adds an audit of the existing site, a content migration, a redirect map and more stakeholders with opinions about what should stay. It also carries the risk of losing search rankings, which is why the audit and redirect steps are scheduled before design rather than after. A redesign that keeps its URLs and content can be faster than one that changes everything.
Talk to us about your project
Tell us what the site has to do and when you need it. We will reply with questions, then a schedule and a fixed-scope quote.
