What Is Included in a Website Design Project?

Two proposals for "a new website" can describe completely different amounts of work. One may include discovery, content structure, a set of templates, a CMS your team can edit, integrations, accessibility testing, a migration with a redirect map and a proper handover. The other may include a homepage design and a promise to "build the rest." Knowing the standard website design project deliverables is the only reliable way to tell which proposal you are looking at, and whether its price is high, low or simply describing a different job.

This guide is for marketing leads, founders and in-house teams commissioning a site, and for anyone who has to defend a web budget to a finance director. It walks through each group of deliverables in the order a project produces them: what each one is, why it matters, what good looks like and what is often missing. Then it covers how scope changes between package types and price tiers, what the handover should contain, which contract terms deserve a careful read, and how to compare proposals side by side.

The aim is practical. By the end you should be able to take any proposal, list what it actually commits to delivering, and spot the gaps before they become change requests.

The short answer: what a complete website design project contains

A complete website design project delivers a working, documented site that your team can run without the agency, plus the thinking and assets that got it there. In practice that means six groups of deliverables: discovery outputs, content and structure, design, build, integrations and data, and testing and launch, followed by a handover package. The exact contents scale with the size of the job, but a project missing any whole group is either very small or incomplete.

Use this list as a baseline when reading proposals. Anything on it that a proposal does not mention should be a question, not an assumption.

Discovery and strategy deliverables

What they are

Discovery is the first phase of the project, usually 1–2 weeks. It produces a short set of documents: a summary of business goals and audiences, a list of constraints (technical, legal, brand, budget), an inventory of the existing site and its content, a list of integrations and who owns them, success measures, and a confirmed scope that the rest of the project is priced against.

Why they matter

Almost every expensive surprise in a web project can be traced to something discovery did not uncover: an integration nobody mentioned, a content set three times larger than expected, an approval step that adds weeks, a legacy system that cannot be switched off. Discovery converts those unknowns into known costs while they are still cheap to plan for. Our practical guide to scoping a website project covers the questions in detail.

What good looks like

• A written summary short enough that your leadership will actually read it.
• A content inventory that counts layouts, not just pages.
• Named owners for each integration and each content area.
• Success measures that can be checked after launch, such as form completions or booked calls, rather than "a modern look."
• A scope statement that says what is out, not only what is in.

What is often missing

The out-of-scope list, and a clear decision on who maintains the site after launch. The second one matters more than it seems: building something you can edit safely costs more up front than building something only the agency can change, and it is almost always the cheaper of the two over three years. That decision shapes the CMS, the templates and the handover, so it belongs in discovery.

Content and structure deliverables

What they are

This group covers the sitemap, the content model and the content plan. The sitemap shows every page and how they are grouped and navigated. The content model defines each page type as a set of fields: a case study might have a client name, sector, challenge, approach, results, images and related services. The content plan says who writes, supplies and approves each piece, and by when.

Why they matter

This phase typically runs 2–4 weeks, and it is the one that slips. Content readiness is one of the biggest cost and schedule drivers in any website project: a site with copy and images ready moves at roughly twice the speed of one where content is written during the build. Designing without real content also produces layouts that break the moment real headlines and real product names are dropped in.

What good looks like

• A content model that matches how your team thinks about its material, so editors know where things go.
• Reusable, structured fields rather than one large rich-text box per page, which makes future redesigns and search features easier.
• A content plan with dates tied to the design and build schedule, so everyone can see what a late case study delays.
• Decisions on which existing content moves, which is rewritten and which is retired.

What is often missing

Ownership. Proposals frequently assume the client will supply "final content" without saying what that means or when it is due. If copywriting is not included, the proposal should say so explicitly, and your internal plan should account for who will write it.

Design deliverables

What they are

Design usually runs 3–6 weeks and produces wireframes, visual designs and a design system. Wireframes set out layout and hierarchy for each template without visual styling. Visual designs apply the brand at mobile and desktop widths, sometimes tablet too. The design system collects the reusable parts: typography scale, color tokens, spacing, grid, buttons, form elements, cards, navigation patterns and states such as hover, focus, error and empty.

Why they matter

Design is where decisions become cheap to change. Moving a block in a wireframe takes minutes; moving it after build can take days. A well-structured design system also reduces build time and makes future pages consistent without needing a designer for each one.

What good looks like

• Every template designed, not just the homepage and one inner page.
• Mobile layouts designed deliberately, not left for developers to improvise. Our guide on how to get responsive design right covers the decisions involved.
• Interactive states designed: focus outlines, form errors, loading and empty states.
• Color contrast and type sizes checked against your accessibility target during design, not after build.
• Designs shown with real content, or realistic content where real content is not yet ready.
• Source design files delivered in an organized, editable form.

What is often missing

States and edge cases. Many design sets show the ideal page with a perfect headline length and nothing on error states, long names, missing images or empty search results. Developers then invent those states on the fly, and consistency suffers. The number of design rounds included is another frequent omission; it should be stated in the proposal.

Build and engineering deliverables

What they are

The build turns designs into working templates on a content management system. It typically takes 4–12 weeks depending on template count. Deliverables include the templates themselves, the configured CMS with the agreed content model, reusable components, hosting and deployment setup, staging and production environments, and the technical SEO foundations.

Why they matter

This is the part of the project you will live with longest. The choices made here, the CMS, the rendering approach, how components are structured, determine how easy the site is to edit, how fast it loads and how expensive it is to change later.

Choosing the platform

The CMS should fit the team that will edit it, not the agency's preference. For many marketing teams the choice comes down to a hosted platform or an open-source one; HubSpot CMS vs WordPress compares two common options. Whatever the platform, the proposal should say which one and why.

What good looks like

• A CMS configured so editors can create and change pages without breaking layouts, using the content model from the structure phase.
• Separate staging and production environments, with a documented way to deploy changes.
• Code in a version-controlled repository you own or can access.
• Technical SEO built in: editable titles and descriptions, canonical URLs, XML sitemaps, clean URL patterns and structured data where it fits the content. Our article on structured data for websites covers where it helps.
• Performance work: optimized images, sensible caching and a page weight budget checked on mobile.

What is often missing

Editor experience. Sites are often built so they look right on launch day but are fragile to edit: a wrong image size breaks a layout, a long title overflows, a new page type needs a developer. Ask to see the editing interface, not just the front end, before you sign off the build.

Integrations, data and tracking deliverables

What they are

Integrations connect the site to other systems: a CRM, a booking system, a payment gateway, a legacy inventory feed, an email platform, search, or a customer login. Tracking covers analytics, conversion events and any tag management.

Why they matter

Integrations are a major cost driver because each one is a separate contract with somebody else's API and somebody else's outage. They also carry most of the commercial value: a form that does not reach the CRM reliably is a site that loses leads quietly.

What good looks like

• Each integration listed individually in the proposal, with what data moves, in which direction, and what happens when the other system is down.
• Error handling and alerts, so a failed form submission is noticed the same day rather than at the end of the quarter.
• A tracking plan that names the events you care about, such as form submissions, bookings and key clicks, and where they are reported.
• Test records run through every integration before launch, with results written down.

What is often missing

Failure behavior and ownership of third-party accounts. Proposals often say "CRM integration" without saying what happens when the CRM rejects a record, or whose account the API keys belong to. Both should be settled before build starts.

Testing, accessibility and launch deliverables

What they are

Testing and launch usually takes 1–3 weeks, plus the redirect map. Deliverables include functional testing across agreed browsers and devices, accessibility testing against a stated target, performance testing, content checks, the migration of existing content, a redirect map from old URLs to new ones, a launch checklist and a post-launch support window.

Accessibility

Meeting WCAG 2.1 AA from the start adds modestly to design and build. Retrofitting it later costs several times more. A proposal should name the target standard and level, and the testing deliverable should include both automated checks and manual testing with a keyboard and a screen reader, with issues and fixes recorded. WCAG 2.2 is the newer version of the same W3C standard, and some organizations now specify it; either way, write the version into the contract.

Migration and redirects

Migration is its own project with its own risks. Moving a thousand existing pages, preserving their URLs and their formatting, is not a line item to accept without detail. The redirect map is the single most important protection for search visibility during a redesign: every old URL that has traffic or links should point to its closest new equivalent. For budgets and schedules specific to this work, see how much a website content migration costs.

What good looks like

• A written test plan listing browsers, devices, templates and user journeys.
• An accessibility report with issues found, severity and status.
• A redirect map reviewed by you before launch, not discovered afterward.
• A launch checklist covering DNS, SSL, analytics, forms, search indexing settings and backups.
• A defined period after launch during which defects are fixed at no extra cost.

What is often missing

Written results. "Tested on all major browsers" is a claim; a list of what was tested and what was fixed is a deliverable. The same applies to accessibility, where a proposal that mentions compliance without naming a standard or a testing method is not committing to much.

These phase ranges describe how a project runs rather than a single calendar. Phases often overlap, with content work continuing while design starts and build beginning on finished templates, so the right schedule for your project comes from the supplier's plan, not from adding the ranges together. Content readiness and the number of templates are the two factors most likely to stretch or compress it.

How scope differs by package and price tier

The deliverables above apply to every project, but their depth varies a great deal with the type of engagement. Our published rates are starting prices, not totals: a quote for your project may be higher depending on templates, content readiness, integrations, accessibility target, migration and who maintains the site.

• Landing page or microsite, from $4,800 per project. One page or a handful, built accessible and fast, on a CMS you can actually edit. Turnaround: 3–5 weeks.
• Marketing site, from $18,000 per project. The usual shape: a set of templates, real content, real integrations, a migration. Turnaround: 8–12 weeks.
• Retained engineering, from $145 per hour. A developer on your stack for an agreed share of each month. Turnaround: start within 2 weeks.

For context, reviewed typical US market ranges are $6,000 – $20,000 for a small marketing site (five to fifteen pages, a handful of templates, a CMS you can actually use, accessible and fast), $20,000 – $75,000 for a business site with systems (custom templates, real integrations, structured content, a migration, and a testing pass that deserves the name), and $75,000+ for a large or complex build (multi-language, complex integrations, design systems, or anything where the site is the product rather than a brochure for it).

The scorecard shows depth, not a hard boundary. A microsite can carry an integration, and a marketing site can skip migration if it is a new brand. If you are unsure which shape fits, landing page vs full website walks through the decision, and website retainer vs project pricing covers when ongoing engineering time makes more sense than a fixed project.

What moves the price within a tier

What the handover should include

The handover is where many projects quietly fail. The site launches, the agency moves on, and six months later nobody can find the hosting login or remember why a template behaves the way it does. A proper handover is a deliverable in its own right and should be listed in the proposal.

Access and ownership

• Administrator access to the CMS, hosting, domain registrar, DNS, analytics, tag manager, search console and every third-party service the site uses, in accounts your organization owns.
• The code repository, transferred or shared, with a note on how to deploy.
• Editable source design files and the design system.
• Licenses for fonts, plugins, themes and stock imagery, in your name where the license allows.

Documentation

• An editor guide: how to create each page type, which fields do what, image sizes and common mistakes.
• A technical overview: architecture, environments, integrations, scheduled tasks and where configuration lives.
• The final redirect map, accessibility report and test results.
• A list of known issues and deferred items, so nothing is forgotten.

Training and support

At least one recorded training session for editors, and a defined post-launch period for defect fixes. After that, ongoing care usually moves to a maintenance arrangement; what is included in a website maintenance plan covers what that should cover, from updates and backups to security monitoring.

Contract terms to check before you sign

A proposal describes the work; the contract decides what happens when things change. These are the terms that most often cause disputes on website projects.

Scope and change control

The contract should reference a scope document that lists templates, integrations and deliverables, and describe how changes are requested, estimated and approved. Look for a clear change request process rather than a vague "reasonable changes" clause, which tends to be interpreted differently by each side when the budget gets tight.

Revision rounds and approvals

How many rounds of design revisions are included, and what counts as a round? What happens if approvals on your side take longer than planned? Many schedules slip because client feedback arrives late; the contract should say how that affects dates and cost.

Content responsibilities and deadlines

If you are supplying content, the contract should say what "final" means, when it is due and what happens if it is late. Given that content and structure is the phase that slips, this clause is worth reading twice.

Intellectual property

Confirm that you own the design and code created for you on final payment, with clear exceptions for the agency's pre-existing tools and third-party licensed components. You should be free to hire someone else to maintain the site.

Acceptance and warranty

Define how the site is accepted (for example, passing the agreed test plan) and how long defects found after launch are fixed without charge. Distinguish defects, where the site does not do what was specified, from new requests.

Payment schedule

Staged payments tied to deliverables, such as discovery sign-off, design approval, build complete and launch, align incentives better than payments tied only to dates.

Hosting, third parties and termination

Who pays for and controls hosting and third-party services? What happens to work in progress, files and access if either side ends the contract early? These are uncomfortable questions at the start and very expensive ones to answer later.

How to compare website proposals

With the deliverable groups and contract terms in mind, comparing proposals becomes a structured exercise rather than a gut decision based on the prettiest pitch deck.

1. Normalize the scope. For each proposal, list the templates, integrations, migration volume, accessibility target and handover items. Where one proposal is silent, ask. Most price differences disappear or become explicable once scopes are laid side by side.
2. Check the discovery commitment. A proposal that skips discovery is pricing a guess. It may look cheaper and end up more expensive through change requests.
3. Look at who does the content. If one supplier includes content structure and a content plan and another assumes you will deliver finished copy, they are quoting different projects.
4. Read the testing and accessibility section closely. Named standards, test plans and written results are commitments; general reassurance is not.
5. Compare the handover. Access, source files, documentation and training should be explicit.
6. Ask about maintenance. Find out what your team can change unaided and what support costs after launch.
7. Weigh the plan, not just the price. A realistic plan with named phases and dependencies is worth more than an optimistic one that has not accounted for content or approvals.

If you are redesigning an existing site, do the preparation before you even request proposals; the website redesign checklist lists what to gather so suppliers can quote accurately. For a view of how we run and check projects ourselves, see our web design and development service page.

Questions to ask in the pitch meeting

Written proposals are edited documents; the conversation around them is where you learn how a supplier really works. A few questions tend to separate teams that have delivered complete projects from teams that have mostly delivered designs.

• "Can you show us the editing interface of a site you built?" A supplier confident in its CMS work will happily share a screen. One that only shows front-end screenshots may not have thought much about editors.
• "What was the last thing that went wrong on a project, and what did you change?" The answer shows whether the team learns from delivery or only from sales.
• "Who will actually do the work?" Ask to meet the designer and developer, not only the account lead, and ask how much of their time is allocated to your project.
• "What do you need from us, and when?" A good supplier will list content, approvals, access and decisions with dates. A vague answer usually means those dependencies have not been planned.
• "What happens in the month after launch?" Listen for a defined fix period, monitoring and a clear route into ongoing support.

An illustrative comparison

The following is an illustrative example, not a real client. Suppose a company receives two proposals for a new site. Proposal A is lower and lists "up to 20 pages, responsive design, contact form, launch." Proposal B is higher and lists discovery, eight templates, a content model, CRM and booking integrations, WCAG 2.1 AA testing with a report, migration of the existing blog with a redirect map, and a handover with documentation and training. When the company asks Proposal A's supplier about templates, integrations, migration and accessibility, each answer is either "not included" or "we can quote for that." Once those items are added as change requests, the two proposals describe similar work, and the difference in price shrinks or reverses. The lesson is not that the higher proposal is always right; it is that the proposals could not be compared until their deliverables were listed the same way.