How to Evaluate a Website Proposal Before You Sign

Hypothetical scenario: the same page count, two different projects

Consider two proposals for a five-page website.

Proposal A includes design, development, a contact form, and launch. The client supplies final copy. Hosting and deployment remain in provider-controlled accounts. Redirects, analytics, and account handoff are not addressed.

Proposal B includes discovery, content drafting, mobile states, forms and notifications, old-URL redirects, analytics setup, testing, launch, and credential handoff.

Proposal B may cost more, but that does not automatically make it better. Proposal A may be entirely appropriate if its exclusions are explicit and the client has a credible plan for the remaining work.

The risk is not a narrow scope. The risk is a narrow scope that appears to be a complete project.

The working rule is:

Normalize scope before comparing price.

Reconcile what was sold with what will be signed

A website project may involve several documents:

• a proposal describing the approach, expected outcome, and price;
• a statement of work, or SOW, defining deliverables, responsibilities, timing, and completion;
• a contract or agreement governing the legal relationship;
• an estimate or quote, whose effect depends on its wording;
• attachments covering specifications, pricing, licenses, schedules, or change orders.

The names vary. The important question is whether the documents describe the same project.

If the sales process promised:

• strategy;
• copywriting;
• search setup;
• a second language;
• integrations;
• analytics;
• post-launch support;

but the SOW includes only “design and development,” ask for the important promises to be included in the SOW, contract, or a clearly incorporated attachment before signing.

Do not treat an oral discussion as traceable written scope until its status is clear. For each important promise, record:

• the document name;
• the section or page;
• the current version and date;
• whether the document is part of the signed package.

Whether a particular proposal or statement is legally binding depends on its text and applicable law. Significant contract questions should be reviewed by a qualified U.S. attorney.

Seven areas every proposal should make visible

The seven areas below describe the substance of the proposed engagement.

These areas are not interchangeable with the fields in the Proposal Risk Ledger. The seven areas show what to review; the Ledger shows how to evaluate each important item.

Build a Proposal Risk Ledger

A question list helps you interview a provider. A risk ledger helps you evaluate what the documents actually resolve.

Evaluate every item across separate fields.

Scope

• INCLUDED
• EXCLUDED
• UNRESOLVED

Responsible party

• CLIENT
• PROVIDER
• SHARED

Client input

Record the facts, assets, approvals, accounts, or decisions the client must provide—and the date or project stage when they are needed.

External dependency

• NONE
• THIRD PARTY

A third-party dependency does not replace project ownership. The documents should still identify who coordinates it, grants access, approves fees, and verifies the result.

Acceptance evidence

Record:

• what must be delivered;
• how it will be tested;
• what evidence confirms the result;
• whether a failure blocks launch.

Document source

Record the proposal, SOW, contract, or attachment—and the relevant section, page, version, and date.

One item may be included, assigned to the provider, dependent on a third-party service, require client access, and be fully defined at the same time.

Use NOT APPLICABLE when a field genuinely does not apply, especially after an item has been explicitly excluded. Do not invent a responsible party or acceptance test for work that is intentionally outside the engagement.

An explicit exclusion is better than a hidden assumption.

“Copywriting is not included; the client supplies approved copy before design” is clear.

“Content will be discussed later” is an exposure that may become a delay, dispute, change request, or additional cost.

Define the actual scope

Page count is only one dimension.

Review five groups.

Pages and content

• routes and page types;
• copywriting and editing;
• images and other assets;
• blog or resource content;
• language versions.

Functions

• forms and notifications;
• calendars;
• CRM;
• payment or email integrations;
• other interactive features.

Migration

• current content;
• files and data;
• old-URL redirects;
• resource or blog migration.

Setup and verification

• analytics;
• Search Console;
• sitemap and robots;
• testing;
• accessibility review;
• performance review.

Launch and handoff

• deployment;
• training;
• credentials;
• documentation;
• backup or rollback;
• transition to support.

Also clarify whether the engagement includes privacy notices and other pages or disclosures that may apply based on the site’s data practices, services, audience, jurisdiction, and business-specific requirements.

Not every project needs every item. The goal is a visible boundary.

Assign responsibility before the project stalls

Website projects often stall because no one owns a material, approval, access request, or decision.

Create a responsibility matrix for positioning, service facts, copy, translations, photography, testimonials, privacy or legal review, integrations, stage approvals, and final launch authorization.

A provider may draft the copy while the business owner verifies services, geography, pricing language, licenses, and operational limitations.

Regulated or professionally sensitive claims may require review by an attorney, accountant, clinician, or another qualified professional.

A third-party service does not become “someone else’s problem.” The proposal should state who coordinates the dependency, provides access, approves recurring fees, and confirms successful operation.

Business Control Map

This map does not provide a legal conclusion. It turns a vague ownership promise into fields the business can inspect and discuss.

Make technology and dependencies visible

The platform matters because of how it is owned, maintained, paid for, and transferred—not because one product name is universally better. Before choosing technology, define the website architecture, design scope, and customer path to inquiry.

Ask:

• why the approach fits the business;
• who can update the site;
• which fees recur;
• what depends on plugins, APIs, or external services;
• whether content and data can be exported;
• how language versions work, when relevant;
• who controls deployment;
• what happens if an external service changes or fails;
• how the site can move to another provider.

“Calendar integration included” is incomplete.

A clearer scope identifies:

• the calendar product;
• where the integration appears;
• which account owns it;
• what data moves between systems;
• what confirmation the customer receives;
• what is tested;
• which third-party fees are excluded;
• what fallback exists if the service fails.

The same discipline applies to CRM, forms, payment services, email automation, chat, and other connected systems. Also verify what should happen after a form submission, call, or message: who captures context, who responds, and how follow-up begins.

Define “done” before launch

Launch is an event. Acceptance is a decision that the delivered work meets the agreed scope.

Possible acceptance areas include:

• agreed pages and content;
• mobile behavior;
• navigation and links;
• forms and notifications;
• language routes;
• page titles and descriptions;
• canonical and hreflang when applicable;
• redirects;
• sitemap and robots;
• analytics and Search Console;
• accessibility review;
• performance review;
• browser and device checks;
• credentials and documentation;
• backup or rollback;
• owner sign-off.

A small project does not need a massive acceptance document. It does need an agreed definition of completion.

For important checks, define the evidence rather than writing only “tested” or “included.”

For accessibility, W3C recommends evaluation early and throughout development, when issues are easier to correct. W3C also states that no automated tool alone can determine whether a site is accessible; knowledgeable human evaluation is required. See Evaluating Web Accessibility.

One Lighthouse score should not be the entire definition of quality. The proposal should identify the checks that matter for the project and which issues block launch.

Separate revisions, change requests, defects, and maintenance

These terms should not be interchangeable.

Revision

A change within an agreed deliverable before approval.

Change request

New or changed scope.

Defect

Delivered behavior that does not meet the agreed result or acceptance criteria.

Maintenance

Post-launch work such as:

• updates;
• backups;
• security;
• content changes;
• integration checks;
• platform care.

The documents should explain:

• included revision rounds;
• how feedback is submitted;
• when a stage is approved;
• how new scope is priced and approved;
• whether a defect-correction period exists;
• what maintenance includes;
• when included support ends;
• who handles urgent failures.

There is no universal correct support period. The problem is an undefined one.

Review evidence, not just portfolio aesthetics

Start with the ProAI Expert case studies: compare not only visual polish, but the stated problem, implemented mechanism, evidence boundaries, and the user’s real next step.

A polished screenshot proves presentation. It does not prove process or business performance.

Identify what you are reviewing:

• a live website;
• a screenshot;
• a Concept Project;
• a template;
• a redesign mockup;
• a case study;
• a testimonial;
• a verified metric.

Ask:

• Is the site live?
• What did the provider actually deliver?
• Is it custom work or a template adaptation?
• Can you inspect mobile behavior?
• Do forms and navigation work?
• Does the case separate outputs from outcomes?
• Are metrics dated, sourced, and limited?
• Is the example comparable to your project?

A Concept Project can legitimately demonstrate strategy, structure, and design direction. It should not be presented as a client result.

A template is not automatically a weakness. The issue is whether the approach is disclosed, suitable, and accurately represented.

Use warning signals without rigid rules

Material warnings include:

• no written scope;
• guaranteed rankings or leads;
• unclear account control;
• undisclosed recurring costs;
• no acceptance process;
• live work claimed with screenshots only and no explanation;
• pressure to sign while important questions remain unresolved;
• no owner for content and factual review.

Other items require context rather than automatic rejection:

• a large deposit;
• a small team;
• template use;
• a proprietary platform;
• a monthly plan;
• remote work;
• AI-assisted production;
• no public pricing.

Ask:

1. What risk does this model create?
2. Is that risk disclosed and acceptable to the business?

A proprietary platform may be well supported and operationally convenient. The proposal should still explain access, export, migration, and what happens when payment ends.

Compare normalized proposals

Compare resolved risk, not the number of bullets.

For every important promise, record the document, section or page, and current version.

Where repeat costs come from

Repeat costs can appear when content, mobile behavior, integrations, migration, access, licenses, verification, or support were not:

• included;
• explicitly excluded;
• assigned to a party;
• connected to acceptance evidence;
• documented in the current proposal package.

This does not always mean deception. The parties may simply have understood an unwritten part of the project differently.

The practical response is to resolve material unknowns in writing before comparing the final totals.

A practical decision sequence

Before signing:

1. Reconcile the sales discussion, proposal, SOW, contract, and attachments.
2. Define scope for each important result.
3. Assign responsibility and client inputs.
4. Record external dependencies and recurring costs.
5. Map legal rights and practical account control.
6. Define acceptance evidence.
7. Record the document source, section, and version.
8. Separate revisions, new scope, defects, and maintenance.
9. Resolve, exclude, or knowingly accept red risks.
10. Compare price last.

The goal is not to eliminate every risk.

The goal is to prevent important risk from hiding inside an assumption.