Web Design Proposal Checklist: What to Check Before You Sign

Two proposals can promise a professional website and still describe completely different projects. One includes interviews, copywriting, redirects, a tested enquiry journey and staff training. The other includes a theme, a few page layouts and a launch button. Comparing their totals without comparing their responsibilities is how a sensible budget becomes an expensive misunderstanding.

A useful web design proposal makes the work inspectable. You should be able to point to a requirement, find the deliverable that meets it, identify who supplies the inputs and understand how completion will be checked. Attractive presentation is welcome, but it cannot substitute for those answers.

This checklist is for business owners reviewing an agency proposal, not designers looking for a sales-document template. Use it after preparing your brief and before approving the commercial agreement. If you have not written the brief yet, start with Webcurry's website design brief template. The examples below are illustrative project scenarios, not client results or market-price claims.

The short answer: what should a web design proposal include?

A complete proposal should define the business objective, page and template scope, functionality, content responsibilities, design process, platform, quality checks, timeline, pricing, ownership, handover and post-launch support. It should also explain exclusions and how changes will be approved.

Look for three kinds of clarity:

• What you receive: named deliverables rather than broad promises such as a modern website.

• What you must provide: content, access, decisions and approvals, each with an owner.

• What happens when circumstances change: additional work, delays, revisions and exit arrangements.

Keep a separate list of unresolved questions. An unanswered question is not automatically a red flag; refusing to answer a material question is a more useful warning.

1. Check whether the agency understood the business problem

The opening section should sound like your business, not a paragraph that could introduce a restaurant, manufacturer or software company unchanged. It should identify your priority audience, why the website is being commissioned and which customer actions matter.

For a specialist repair business, the objective might be helping visitors confirm service coverage and submit a qualified request. For a manufacturer, it might be making capabilities, specifications and enquiry requirements easier to find. These objectives lead to different page structures and forms.

Ask the agency to distinguish the website's contribution from the wider marketing plan. A better enquiry journey is a reasonable design objective. A guaranteed number of leads, a guaranteed search position or a guaranteed revenue increase is not a substitute for explaining the work.

Turn a broad objective into a testable deliverable

Instead of accepting “improve conversions,” ask for a description such as: create a service enquiry journey with clear eligibility information, a short form, an acknowledgement message and verified delivery to the agreed destination. That specifies work you can examine without pretending the agency controls every visitor's decision.

2. Separate page count from template count

“Ten pages” is not enough information. Ten individually designed layouts are different from ten service pages that share one reusable template. Neither approach is inherently better, but the proposal should state which one you are buying.

Request a page inventory that distinguishes unique layouts, repeated templates and content entries. Include less glamorous screens: search results, empty states, thank-you messages, form errors, the blog listing and the not-found page. Important customer journeys often pass through those screens.

For example, a project could include one homepage layout, one service template populated six times, an about page, a contact page and a blog template. If six service pages need different content arrangements, say so before design begins.

Also ask who populates the templates. Building a case-study template does not necessarily include entering twenty case studies. The proposal should distinguish creating the system from loading and checking its content.

3. Translate every feature into a real customer journey

Feature names hide assumptions. A booking system might mean a link to an external calendar, an embedded appointment widget or a complete workflow with staff availability, reminders and rescheduling. The label alone cannot tell you the scope.

For each important feature, describe the start, the successful outcome and the failure state. A quote request begins when a visitor selects a service and ends when the right person receives enough information to respond. An error message, duplicate submission or missing notification is part of that journey too.

Clarify who configures each external service and who pays its ongoing charges. If the site connects to a CRM, identify the fields being transferred, the destination, the matching behaviour and the test that proves the connection works.

Ask for exclusions in ordinary language. “No custom integration development” is much clearer when accompanied by the exact native integration the agency intends to use and what happens if it does not support a required field.

4. Find out who is responsible for the words and images

Content is a delivery dependency, not a decorative finishing touch. A design schedule can look realistic until everyone discovers that nobody is writing the service descriptions or locating usable project photographs.

The proposal should distinguish content strategy, new copywriting, editing supplied copy and simply pasting approved text into pages. These are different services. Ask how many pages are covered, how feedback is handled and who verifies business claims.

For images, specify whether the work includes selecting stock assets, organising a shoot, editing existing photographs or producing illustrations. Record licence responsibilities and whether editable design files are included. Do not assume an image found online is available for commercial use.

Decide how placeholders will be handled

Temporary copy can support layout approval, but it should not silently become final copy. Add a launch check for invented testimonials, unsupported claims, sample addresses, generic team biographies and placeholder pricing. If AI assists with drafting, a named person still needs to verify the facts and approve the final wording.

5. Understand the design process and revision boundaries

Ask what you will approve at each stage. A sensible sequence might include sitemap, key-page wireframes, visual direction, responsive layouts and the implemented site. The exact sequence can vary; the important point is that expensive decisions are not left until after development.

“Two revisions” needs a definition. Does one revision mean a consolidated feedback round on the whole phase, or a change to one element? Can different stakeholders submit conflicting instructions? What happens if a previously approved layout is reopened?

Agree on one decision-maker who collects internal feedback. Give the agency a single, prioritised response rather than a stream of contradictory messages. Ask the proposal to identify the feedback window and the consequence of missing it.

Revisions should not be confused with fixing defects. A button that does not perform its agreed action is different from deciding, after approval, to add a new customer journey. The proposal should make that distinction explicit.

6. Ask why the proposed platform fits your operation

The platform recommendation should connect to how the business will use the site. Consider who will edit it, the content types it needs, the integrations involved and the skills available after launch. “We always use this platform” is not a complete explanation.

Ask the agency to show the editing tasks your team will perform: changing a service description, publishing a case study, replacing an image and managing an enquiry. A demonstration is more useful than an assurance that the site will be easy to update.

Record any dependency on premium apps, themes, plugins, custom code or an agency-managed service. Ask what remains operational if you stop the maintenance contract and which subscriptions would need replacing or transferring.

If you are comparing a self-build route with professional delivery, use the AI website builder versus web design agency guide to separate platform capabilities from the work someone must still perform.

7. Make SEO deliverables specific, especially during a redesign

“SEO included” can mean almost anything. Ask whether the scope includes page-intent planning, titles and descriptions, heading structure, crawlability checks, internal links, image alternatives and Search Console access. Separate launch essentials from an ongoing content or authority-building service.

For an existing website, request an inventory of valuable URLs before the structure changes. The proposal should identify responsibility for redirect mapping, content preservation, canonical checks and post-launch monitoring. A redirect plan created after traffic disappears is late.

Google's site-move guidance is a useful primary reference for projects that change URLs. Use it to inform the migration scope, not to demand a guarantee that rankings will remain unchanged.

Webcurry's guide to ranking losses after a website redesign explains the kinds of technical omissions worth checking before launch. The proposal should say who checks them and who fixes problems found during acceptance.

8. Define accessibility, mobile and performance checks

Terms such as responsive, accessible and fast should lead to an agreed testing method. Ask which representative page types and customer journeys will be tested, which browsers and devices matter, and how issues will be prioritised.

Accessibility work should include human review rather than relying only on an automated badge or score. The W3C accessibility evaluation overview explains that no tool alone can determine whether a site meets accessibility standards. Ask for the intended standard, evaluation scope and evidence of checks performed.

For mobile usability, test actual tasks: open the menu, read a service page, complete the form and recover from an error. A screenshot at a smaller width cannot prove those interactions work.

For performance, agree on representative pages and test conditions. A single perfect score is a weak acceptance rule if it excludes the real images, analytics, consent interface and integrations that will appear on the published site.

9. Connect the timeline to dependencies and approvals

A proposal should explain the sequence of work, not just promise delivery by a date. Identify milestones, inputs needed at each milestone and the person authorised to approve them. Check whether the schedule starts at payment, kickoff or receipt of all required materials.

If the site must launch before an event, ask which requirements are essential for the first release and which can wait. A smaller, tested launch can be preferable to rushing every requested feature into an unreviewed release.

Include time for content checking, customer-journey testing, corrections and handover. Those tasks are part of delivery, not unexpected extras that appear after design approval.

Ask what happens when either side misses a dependency. The answer should explain communication, rescheduling and any commercial consequence. Avoid assuming that silence counts as approval unless the agreement explicitly addresses it and you understand the implications.

10. Compare total scope and recurring costs, not just the headline fee

Separate the one-time project fee from recurring platform, hosting, domain, app, maintenance and support charges. Ask which amounts are fixed, which are estimates and which are paid directly to third parties. Check the applicable currency and whether stated totals include relevant taxes.

Then compare milestone payments with milestone deliverables. You should understand what work each payment corresponds to and the agreed process if a milestone is disputed or delayed. Commercial terms deserve careful review; this checklist is not a substitute for legal advice on your agreement.

Ask how additional work is estimated and authorised. A written change request should explain the new requirement, fee impact and schedule impact before the work begins. Informal enthusiasm during a call is not a reliable scope-management system.

For ongoing budgeting, use the categories in Webcurry's website maintenance cost guide. Obtain current quotations for your actual requirements rather than treating a generic online range as your final budget.

11. Put ownership, access and handover in writing

Ask what will be transferred or licensed, when that happens and what is excluded. Discuss the domain registration, platform account, content, custom design work, code, source files, analytics and third-party assets separately. “You own the website” is too broad to resolve each item.

Operational access matters alongside contractual rights. Your business should know who can renew the domain, manage billing, approve collaborators and recover the primary accounts. A login that only edits page text is not the same as ownership-level control.

Require a handover list: account invitations, documentation, training, asset files, renewal dates, integration notes and a record of unresolved issues. Identify any agency-managed licences that cannot simply be transferred.

Use the website ownership and agency handover guide for a more detailed asset-by-asset review. Settle these questions while choosing the engagement, not only when a relationship ends.

12. Specify acceptance and post-launch support

Acceptance should involve a shared checklist. The published site should contain the approved content, the agreed journeys should work, essential links should resolve and the business should have the promised access. Record which issues block launch and which can enter a scheduled follow-up list.

Support language should distinguish defect correction, routine maintenance and new work. Ask about the covered period, contact channel, operating hours and response expectations. A response target is not necessarily a resolution guarantee.

Check who monitors the first real enquiries or orders. A form can pass a preview test yet fail because of a live routing configuration or a third-party change. Agree who investigates and how evidence will be shared without exposing customer data unnecessarily.

Finally, ask what happens when the included support period ends. You should be able to choose an ongoing arrangement with clear deliverables rather than discovering that ordinary editing depends on an unspecified monthly service.

A worked example: comparing two proposals fairly

Imagine a local equipment supplier commissioning a lead-generation website. Both agencies propose eight pages. Proposal A includes interviews, edited service copy, migration of existing URLs, enquiry routing tests and training. Proposal B includes layout design and implementation using content supplied by the client.

Neither document is automatically wrong. Proposal B may suit a business with a capable internal writer and an existing technical team. Proposal A may be the better fit when the owner needs someone to coordinate the complete project.

Create a comparison sheet with one row per requirement. For each agency, record included, excluded or unclear, followed by the deliverable and responsible person. Do not fill an unclear cell with a hopeful assumption.

Then send both agencies the same outstanding questions. If Proposal B adds copywriting and migration, compare the revised scope and total. If those tasks remain internal, include the staff time and coordination burden in your decision.

This method gives you a defensible choice. You are comparing two delivery arrangements, not trying to infer project quality from the length of a PDF or the size of a discount.

Your final proposal review sheet

Before approving the project, you should be able to complete these sentences without guessing:

• Our primary audience is defined, and the main customer action is clear.

• We know which pages, templates and content entries are included.

• Every important feature has a working-outcome test.

• Content, access, feedback and approvals each have an owner.

• SEO, accessibility, mobile and performance checks have an agreed scope.

• We understand the project fee, recurring costs and change process.

• Ownership, licences, account control and handover are documented.

• Acceptance, defect handling and ongoing support are clearly separated.

Keep the final proposal version with the signed agreement and approved scope. If email clarifications change the deliverables, make sure the final documents reflect those changes. A collection of scattered messages is difficult for either team to deliver against.

Frequently asked questions

Is a web design proposal the same as a contract?

Do not assume they are interchangeable. A proposal describes the offered work, while the applicable agreement sets the terms of the engagement. Their relationship depends on the documents and how they are accepted. Ask which version controls the scope and obtain legal advice where the commercial or ownership terms need interpretation.

How many agencies should receive my brief?

Choose a manageable shortlist that you can evaluate properly. Give each agency the same core brief, required outcomes and known constraints. A large pile of quotes is less useful than a few comparable proposals accompanied by clear answers, relevant examples and a discussion with the people responsible for delivery.

Should the proposal include the exact number of pages?

It should define the initial page inventory and distinguish unique layouts from reusable templates and content entries. It should also explain how later additions are priced. A page count alone does not reveal the amount of design, writing, data entry or testing included in the project.

What does SEO included usually mean?

The phrase has no sufficiently precise meaning for a scope comparison. Ask for named deliverables, such as page titles, crawlability checks, redirect mapping or internal linking. Establish whether ongoing research, content creation and performance review are separate services. Do not treat the phrase as a promise of rankings or traffic.

Should I ask for unlimited design revisions?

Clear review stages are generally more useful than an undefined promise of unlimited revisions. Agree on feedback rounds, decision-makers and what happens when an approved direction changes. Keep corrections to agreed functionality separate from new preferences or additional features so both sides understand the work being requested.

How do I compare a low quote with a much higher quote?

Compare deliverables, exclusions, responsibilities, recurring costs and support first. Identify tasks that one quote includes and the other leaves to you. Ask for clarification before judging value. A lower quote can be appropriate for a smaller scope, while a higher quote still needs evidence that its additional work matters.

Must an agency guarantee a PageSpeed score?

A proposal should define performance testing and responsibility for addressing issues, but a score without test conditions is a weak commitment. Specify representative pages, published content and required third-party services. Review the actual customer experience as well as test results, and separate launch testing from ongoing monitoring.

Who should approve the final website?

Name a business decision-maker who can consolidate feedback and approve the agreed acceptance checklist. Involve the people who will manage content and enquiries, but avoid conflicting approvals from several channels. The agency should identify its delivery lead and explain how unresolved issues are documented before launch.

What if the project requirements change halfway through?

Use the agreed change-control process. Describe the new requirement, ask for its fee and timeline impact, and approve it in writing before implementation. Decide whether it replaces existing work, enters a later phase or expands the current scope. Update the project record so both teams work from the same decision.

What should I receive at handover?

Request the agreed account access, transferable assets, licence information, renewal schedule, editing instructions and integration documentation. Include training and a record of any open issues. Test that your team can complete its ordinary tasks. The exact handover should match the platform, project scope and rights documented in your agreement.

Choose the proposal you can actually manage

A strong proposal reduces uncertainty for both the business and the agency. It makes the important decisions visible before time and money are committed, and it gives both teams a practical definition of done.

If you are preparing a project, bring your current website, priority customer journey and draft brief to Webcurry. A useful first conversation should clarify the work, the responsibilities and the questions that need answering before anyone promises a launch date.