Almost every guide to website proposals is written for the person sending it — how a designer should structure a proposal to win the work. This is the other side of the table: how to read one before you sign, so that the ambiguity in it becomes your question today instead of your delay, change order, or ownership fight three months from now.

There's a single test that does most of the work. Hand the proposal to a capable person who wasn't on any of the sales calls and ask them to explain what both sides are about to do. If they can — the current problem, who the site is for, what's being built, who's responsible for what, what it costs now and later, and how you'll know it's finished — the proposal is doing its job. If they keep having to say "I think this is what they mean," the gaps are real, and a polished mockup won't fill them.

A quick boundary before the details: this is general business education, not legal advice. A proposal might be folded into a contract, sit beside a statement of work, or contain binding terms on its own — the label on the document matters far less than what the whole agreement says. Have qualified counsel review the agreement when the cost or risk warrants it, and have qualified counsel review ownership and exit terms specifically.

First, figure out what you're actually signing

This is the step most buyers skip, and it's the one that decides which of the other steps even matter. Website engagements often ride on several documents at once. A proposal makes the case and describes the approach. A statement of work pins down project-specific deliverables, responsibilities, assumptions, timing, and fees. A master services agreement or similar contract supplies the general legal and operating terms. Platform, hosting, software, privacy, and payment terms may be pulled in by reference without appearing in the document you're reading.

Providers use these labels differently, so don't assume a "proposal" is nonbinding or that a "statement of work" contains the whole deal. Look for language that incorporates one document into another, links to external terms, an order of precedence, and signature blocks. Then ask the one question that resolves the rest: if two sections conflict, which one controls? Collecting the complete set and answering that is also the most useful thing you can hand to a lawyer, because it's the part they can't reconstruct from a single page.

Ten places to look, and what "clear" means in each

1. The diagnosis

The proposal should say why a redesign is being recommended, in terms you could verify. "The current website is outdated and doesn't reflect the brand" is a mood. "The site combines three services on one page, sends inquiries to a single employee's inbox, and has 42 indexed URLs with no keep/redirect/retire decision yet" is a diagnosis — it gives the project something to solve and something to check. The provider doesn't need every answer before discovery, but they should separate what they've verified from what they're assuming, and note which problems could be fixed without a full redesign at all.

2. Goals the provider can actually control

Goals should describe the site's job without turning into promises the provider can't keep. "Increase leads" is a business ambition — traffic quality, your offer, pricing, competition, and human follow-up all move it, and none of them is a web page. A controllable goal reads more like: make the three services understandable, give each its own conversion path, preserve the agreed search-relevant URLs, store every valid submission in an inspectable record, notify named roles, and hand you admin access to the agreed accounts. Those conditions can support better results without pretending a website vendor runs your sales system. Look for a clean line between what the site will do, what the provider will advise on, and what you have to operate yourself.

3. Scope and deliverables — where nouns hide work

"Eight-page website" doesn't tell you which eight pages, whether legal pages count, whether service or location templates can spawn more, who writes the content, how many unique designs are included, which forms and tracking events come with it, or whether old content and redirects are in scope. Ask for an inventory of pages, page types, components, content, integrations, and launch work — and if discovery has to set the final list, ask how the allowance, decision process, and pricing for the result are defined.

You don't need to rebuild a full responsibility map here; that's the job of the pre-purchase scope worksheet, and it's worth filling out alongside the proposal. What this section adds is one discipline specific to reading a document: separate what the provider will install from what they'll demonstrate. Adding an analytics tag is installation; showing the correct property receiving the agreed events is demonstration. Placing a contact form is installation; showing the visitor response, the saved record, and the notification is demonstration. A proposal that only promises the first has left the harder half unpriced.

4. Who does what

Every project has client work, and hiding it doesn't make the service more full-service — it makes the schedule imaginary. Look for named responsibility on your side for business facts, credentials and proof, legal and policy text, photography and brand files, access to your domain/hosting/analytics, content review, technical contacts, decisions, and approval deadlines. Then hold the provider's side to the same standard: who runs discovery, who writes, who configures accounts, who enters content, who tests forms and redirects, who watches the launch. "Client will provide timely feedback" is fair but incomplete — ask how much time, what counts as approval, and what happens when your own stakeholders disagree with each other.

5. Assumptions, dependencies, and exclusions

This is where a proposal tells you what its price is built on — no custom integration work, final content by a named date, one language, a product catalog under some size, admin access to the current platform, accessibility testing that excludes third-party widgets, no legal or policy drafting. Specific assumptions make a price more dependable; vague exclusions quietly move the uncertainty onto you. For any assumption that carries real money, ask what happens when it turns out false: does the team cut scope, substitute a method, issue a change order, or stop and wait for a decision?

6. Process and milestones

A timeline should show the path to decisions, not just a launch date. Useful milestones might be discovery complete, sitemap and page jobs approved, content ready, design direction approved, build ready for content, integrations configured, redirects and launch plan approved, acceptance testing complete, launch verified. For each one, ask what's delivered, who reviews it, how long the review window is, what counts as approval, how many revision rounds are included, and what later work waits on this decision. Without that sequence, "12-week project" might mean twelve weeks of production or six weeks of production plus an unknown amount of waiting on approvals — The website timeline article covers what actually drives that clock.

7. Acceptance and evidence

"Client satisfaction" sounds warm and is nearly impossible to administer; "conforms to the agreed design and functional acceptance checklist" can actually be evaluated. The proposal should say how important deliverables get accepted — approved page designs, browser and device checks, form tests, redirect results, access confirmation, analytics event checks, a content-inventory reconciliation, accessibility checks, and a written list of known exceptions. Where established URLs are changing, Google's site-move guidance calls for a map from old to new, tested redirects, updated internal links and canonicals, and monitoring — so ask where those receipts show up in the proposal (and see how to redesign without losing search visibility). Acceptance evidence protects both sides: it tells you what "done" means and keeps the provider from chasing unlimited preference changes after the agreed work passes.

8. Price, payment, and recurring cost

The headline fee is one layer. Look for the payment schedule and due dates, deposit and cancellation terms, taxes, expenses, the platform/hosting/domain/plugin/font/image/integration costs, recurring support fees, renewal timing and price-change terms, any usage limits, and the consequences of late payment. Ask which subscriptions you'll pay directly and which the provider resells — direct billing can simplify ownership but adds account-management work, while provider billing can simplify operations but makes the exit terms matter more. As one current example of a provider showing launch and recurring prices together: as of July 15, 2026, RP Marketing Group's public page lists a Lead Website at $6,500 plus $79 per month and a Connected Lead System at $13,500 plus $199 per month, with the first 90 days of the monthly included. That's an illustration of the format, not a market average, and it should be checked against the live page; The website redesign cost article covers what actually drives a redesign number.

9. Ownership, access, and exit

Don't let one sentence — "Client owns the website upon final payment" — stand in for an asset inventory. The proposal should at least address the domain, hosting and platform accounts, content, custom code and design files, licensed fonts and photos, analytics and Search Console, form and business data, integrations, credentials, and backups. And it should respect that ownership, license, access, and account control are four different things: you might own the copy, license a font, hold admin access to a platform, and have no right to reuse the provider's internal component library elsewhere. This section only needs to confirm the proposal takes those distinctions seriously; those details deserve a separate ownership-and-exit review, with qualified legal advice when the stakes warrant it.

10. Changes, delay, support, and termination

Projects discover things and clients change their minds; a good proposal treats both as normal, not as misconduct. Look for a change process — who can request one, how price and schedule impact are presented, whether work pauses pending approval, how unused allowances are handled, and what happens if you disagree. Inspect the delay and termination terms too: what happens when access or content is late, whether either side can pause or terminate, which fees are earned or refundable, what's delivered at termination, how fast access is transferred, what happens to live hosting/forms/domains, and whether transition help is included, billable, or excluded. Finally, separate a defect-correction period from ongoing support — fixing something that didn't match the accepted scope is not the same as adding a feature next quarter.

Phrases that need one more question

None of these is wrong. Each just carries price or risk that the plain words hide, so each earns a follow-up before you sign.

Proposal phrase The question that unpacks it
"SEO included" Which specific search foundations and migration tasks, and what's explicitly excluded?
"Responsive website" Which devices, browsers, layouts, and key actions will be tested?
"Custom design" What's original, what's reused, and which design files are delivered?
"Content support" Who interviews, writes, edits, enters, and approves each page?
"CRM integration" Embed, native connector, automation, or custom work — and what proves the handoff?
"Analytics setup" Which account, property, events, permissions, and verification?
"Accessibility compliant" Against which standard, tested how, with which exclusions, backed by whose legal judgment?
"Unlimited revisions" Unlimited until which milestone, within what scope, through which decision-maker?
"Ongoing maintenance" Which systems are monitored, updated, backed up, restored, and supported?
"You own the website" Which assets and accounts are owned, licensed, controlled, exportable, and delivered at exit?
"Launch support" For how long, during which hours, for which failures, with what response boundary?
"Results-driven" Which controllable conditions are delivered, and which outcomes are explicitly not guaranteed?

The point isn't to interrogate ordinary language out of existence. It's to make the handful of phrases that move money say what they mean.

A one-page check before you sign

Mark each item clear, unclear, or not applicable. Every important "unclear" becomes a written question whose answer goes into the controlling documents — not into a sales-call memory nobody will consult at launch.

Problem and result: the verified problem is stated; assumptions are separated from facts; the site's audience and intended actions are stated; controllable goals are distinguished from hoped-for outcomes.

Scope: pages and page types are listed or governed by an allowance; content responsibility is explicit; forms, phone actions, integrations, and analytics are explicit; old content and URLs have a migration owner; search and accessibility language is specific enough to verify.

Process: milestones, reviewers, approval windows, and revision rounds are stated; client and provider responsibilities are named; dependencies and exclusions are visible; acceptance evidence is defined.

Money: project fee and payment schedule are clear; third-party and recurring costs are clear; change-order pricing is clear; pause, cancellation, and termination consequences are clear.

Ownership and aftercare: every important asset and account has an owner; licensed assets and limits are identified; handoff and exit deliverables are stated; launch warranty and ongoing support are distinguished; you can explain what happens if the provider vanishes.

The decision the proposal should make easy

A strong proposal doesn't remove uncertainty — it shows you where uncertainty remains and gives both sides a way to resolve it. That's what makes it easy to say yes to and, just as importantly, safe to say no to: you can see what the money buys, what work stays yours, and what evidence will exist when the site is live. If the document in front of you can't give a capable stranger that picture, the right move isn't a bigger deposit. It's a written list of the questions it left open — and their answers added to the agreement before you sign.

Sources