Summary
- A timeline is only as reliable as the scope behind it. Count unique templates and functionality, not pages.
- Many delays come from inputs: content, approvals, access and third-party accounts.
- Agree launch dependencies and who owns them before committing to a date with your client.
Why timelines slip
Most website timelines aren’t missed because the build was slow. They slip because something the build depended on arrived late, changed, or turned out to be bigger than expected. Clarifying these points before agreeing a date protects your agency’s promise to its client.
Scope in writing
Start with a written list of deliverables: which templates, which functionality, which integrations, and what is explicitly not included. “A ten-page website” describes a page count, not a scope. Ten pages using two templates are very different from ten pages that are each unique.
Unique templates
Production effort depends far more on the number of distinct layouts than on the number of pages. Group the design into templates such as homepage, service page, article, archive and contact, and count those. Also count reusable sections, since a flexible section library takes longer to build than fixed pages but saves time later.
Content readiness
Ask directly: is final copy written, approved and ready to add? Are images selected and licensed? If not, decide whether production starts with placeholders, who adds final content, and when. Content arriving late is one of the most common reasons a finished build can’t launch.
Integrations
Every connection to another system adds questions: CRMs, email platforms, payment gateways, booking tools, inventory systems. For each, confirm who owns the account, whether there is a test environment, who can grant access, and what should happen when the integration fails.
Approvals
Agree how many review rounds are included, who gives feedback on the agency and client side, and how quickly. A two-day build step can easily become a two-week wait for approval. Consolidated feedback from one person per side keeps reviews efficient.
Migration
If the project replaces an existing website, find out what has to move: pages, posts, products, users, media, forms and old URLs that need redirects. Migration is often underestimated because the existing site has grown over years and nobody has a complete list of what it contains.
Launch dependencies
Finally, list everything outside the build that has to be ready on launch day:
- Domain and DNS access, and who controls them.
- Hosting account, SSL and email settings.
- Live payment, analytics and marketing accounts.
- Legal pages such as privacy and terms, supplied by the client.
- A redirect plan for old URLs.
Give each dependency an owner and a date. The production timeline can then show clearly which dates depend on the build and which depend on decisions elsewhere.
Checklist
- Written list of deliverables and exclusions
- Number of unique templates and reusable sections
- Final content and image status
- Each integration: account owner, test access, failure behaviour
- Review rounds, reviewers and response times
- Migration inventory and redirect needs
- Launch dependencies with owners and dates