Start with deliverables, not a page count.
“Design and build a new website” leaves major decisions hidden. It may not say who writes the copy, supplies imagery, maps old URLs, tests forms, approves legal text, or maintains the site after launch. Clear boundaries protect both sides.
List the page types and their distinct jobs. A service template, resource article, location page, and contact page may use different structures even when they share visual rules. Record which types will be designed, developed, populated, and checked. Distinguish a reusable template from the number of records that will use it. Ten empty service records are not the same deliverable as ten researched, written, and approved service pages.
Name the states that matter. Does the form need success, error, and validation messages? Does a filtered archive need a no-results state? Will the site support a light and dark theme, translated copy, or unusually long content? These requirements affect scope even when they do not add visible pages to the sitemap.
If the audience and core message are still unsettled, complete the one-page creative brief template first. It captures the communication problem. This page addresses the delivery boundaries around a website build.
Expose dependencies that can block progress.
Record what the website team needs from the owner: current offers, approved pricing rules, account access, brand assets, content sources, legal language, photographs, and proof permission. Put an owner and due point beside each dependency. If a missing input prevents an accurate page, say so before final review. Do not replace missing business facts with polished guesses.
Platform decisions create dependencies too. A booking form may require an existing account and a named person to manage availability. Analytics may depend on consent configuration and access to the property. A content migration may require an export, URL inventory, and editorial cleanup. These are not merely technical details. They determine whether the proposed site can operate.
Draw the line around migration and launch.
Ask who inventories old URLs, writes redirects, transfers content, checks metadata, reviews imported images, and verifies links after launch. A proposal can include all of this or assign part of it to the owner. Either is workable if the division is explicit. The same applies to hosting, backups, email deliverability, and post-launch support.
Define the acceptance evidence. A designed form is not a tested form. A copied article is not an approved article. A page visible in staging is not necessarily published. Record which state counts as delivery for each workstream and which checks happen before the owner promotes the site.
Plan for changes without turning every question into a dispute.
New information often appears after work begins. Agree on how the team handles a changed offer, added integration, new page type, or revised content requirement. A change request should state the new work, its effect on schedule and cost, and who approves it. Small clarifications may fit existing scope. A new functional flow may not. The point is to make the tradeoff visible.
What would you be surprised to learn is excluded after signing? Ask that question from both the owner’s and delivery team’s side. Their answers belong in the scope record.
Settle every ambiguous responsibility.
Bring the proposed deliverables and dependency list to a project conversation. Web development can clarify build and integration boundaries, while web design can clarify page-family and experience scope. Talk to a Specialist about any responsibility that still feels ambiguous.
