DECISION DOCUMENT · Website Strategy & Conversion

How to Evaluate a Website Proposal Before You Sign

Compare website proposals by scope, responsibilities, ownership, acceptance, and support—not page count or price alone.

13 min read2026-08-01Updated 2026-08-02

DECISION

Normalize scope, responsibilities, ownership, dependencies, acceptance evidence, and support before comparing price.

ACCEPTANCE RULE

A proposal is decision-ready when material responsibilities, exclusions, handoff conditions, and definitions of done are explicit enough to verify.

RISK BOUNDARY

No document removes project risk. The objective is to make material risks visible so they can be resolved, excluded, priced, or knowingly accepted.

WRITTEN BYIhor Horb

Founder, ProAI Expert · AI systems, automation, website strategy, and service-business operations.

View profile →

Two website proposals can list the same number of pages and describe different projects.

One “five-page website” may cover design and development only. Another may include copy, mobile behavior, forms, redirects, analytics, testing, launch, and account handoff.

Until those scopes are normalized, comparing the totals tells you very little.

The first question should not be:

Which proposal is cheaper?

It should be:

Which proposal leaves fewer important responsibilities, dependencies, and completion standards undefined?

This guide gives U.S. service-business owners a practical system for reviewing a website proposal before signing.

This is general business information, not legal advice about a specific proposal or contract.

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.

Seven areas every proposal should make visible
Area	What should be clear	Risk if undefined
Business objective	Audience, priority services, geography, decision, and next step	A polished but irrelevant result
Scope	Pages, functions, versions, stages, and exclusions	Change orders and mismatched expectations
Content and responsibility	Who writes, supplies, verifies, and approves	Stalled work or inaccurate publication
Technology and dependencies	Platform, hosting, integrations, recurring costs	Hidden constraints and vendor dependency
Rights and practical control	Accounts, licenses, billing, access, and transfer	The business cannot operate or move the asset
Acceptance	How delivery is tested and approved	“Done” means different things to each party
Post-launch support	Revisions, defects, maintenance, and support boundaries	Corrections become an undefined new project

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.

Build a Proposal Risk Ledger
Item or required result	Scope	Responsible party	Client input	External dependency	Acceptance evidence	Document source	Open question
Service-page copy	Named pages, sections, and revision rounds	Copy owner named in the SOW	Service facts, offers, and approvals	Legal/compliance review if needed	Approved copy mapped to pages	Proposal / SOW: content	Who approves final claims?
Contact form	Fields, routing, confirmation, and spam control	Implementation owner	Recipients, CRM rules, and consent copy	Email or CRM provider	Test submission plus delivered notification	Proposal / SOW: forms	What happens on delivery failure?
Mobile behavior	Primary templates and agreed responsive states	Frontend owner	Priority devices and content constraints	Browser and device behavior	Viewport QA screenshots or checklist	Acceptance / QA section	Which defects block launch?
Redirects	Legacy URL map and redirect rules	Migration owner	Old URL inventory	Hosting, DNS, or CDN as applicable	301 tests and no broken priority URLs	Migration / launch plan	Who owns missing legacy URLs?
Analytics	Named analytics, tags, and conversions	Analytics implementation owner	Account access and conversion definitions	Analytics or tag platform	Debug or realtime verification	Analytics scope	Which events are required at launch?
Launch and handoff	Deploy, DNS, backup, and access transfer	Launch owner	Final approval and account access	Registrar, hosting, and CMS	Production checklist and admin access confirmed	Launch / handoff section	What support starts after launch?

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.

Confirm the business objective

A weak scope may promise a “modern, professional, high-converting website” without defining what the visitor should understand or do.

The written project should identify, at an appropriate level:

the primary audience;
the priority services;
the service area;
the customer decision the site must support;
the primary next step;
important exclusions or claims the site must not make;
facts that require owner or professional approval.

The proposal does not need to contain a complete strategy before discovery begins. It does need to show whether strategy is included as a defined phase or excluded from the engagement.

A common mismatch occurs when strategy is sold verbally but the written scope covers production only.

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.

Launch and handoff
Component	Scope	Responsible party	Client input	External dependency	Acceptance evidence	Document source
Service copy	Included pages, content depth, and revision limit	Copy owner	Service facts and approval	Legal or subject review if needed	Approved final copy on named pages	Content scope / SOW
Second language	Named pages, localization depth, and QA	Translation/localization owner	Glossary, terminology, and approvals	Translator or localization resource	Approved language version on named routes	Language scope / SOW
Forms	Fields, validation, routing, confirmation, and spam control	Implementation owner	Recipients, CRM rules, and required notices	Email or CRM provider	Successful test submissions and notifications	Forms / integrations scope
Redirects	Legacy-to-new URL mapping	Migration owner	Old URL list and priority pages	Hosting or CDN behavior	Tested redirect map with intended status codes	Migration / launch plan
Analytics	Named tools, tags, events, and conversions	Analytics owner	Account access and conversion definitions	Analytics/tag provider	Agreed events visible in test or realtime view	Analytics scope
Deployment	Production publish, DNS, rollback, and handoff	Launch owner	Approval and account access	Registrar, hosting, and CMS	Production checklist completed and access confirmed	Launch / handoff section

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.

Assign responsibility before the project stalls
Component	Scope	Responsible party	Client input	External dependency	Acceptance evidence	Document source
Positioning	Audience, priority services, geography, and promise	Client decision / strategist synthesis	Business goals, priorities, and exclusions	Market or legal constraints if relevant	Approved positioning brief	Discovery / strategy scope
Service facts	Offers, service areas, constraints, and proof points	Client fact owner	Accurate source facts and supporting material	Licensing or compliance facts if relevant	Fact sheet approved before publication	Content responsibility section
Copy	Page-level messaging and revision rounds	Named copy owner	Facts, offers, tone, and approvals	Subject or legal review if required	Approved copy mapped to pages	Content scope / SOW
Translation	Named languages, pages, terminology, and localization depth	Translation/localization owner	Glossary, preferred terms, and approvals	Translator or localization resource	Approved localized pages	Language scope
Photography	Required subjects, formats, licenses, and delivery dates	Named asset owner	Existing assets or shoot access	Photographer, stock, or licensing provider	Approved production-ready assets	Asset / content scope
Privacy/legal review	Privacy, consent, regulated claims, and legal wording in scope	Client decision owner / reviewer named in scope	Policies, required notices, and business constraints	Legal review when required by the business	Approved wording or documented exclusion	Legal / compliance responsibility
Integrations	Named systems, data flow, credentials, and test path	Integration owner	Account access and business rules	Third-party platform or API	Successful agreed test cases	Integration scope
Final approval	Pages, content, functions, and launch decision	Named client approver	Consolidated final decision	Stakeholder approval if required	Written approval or signed acceptance	Acceptance / launch section

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.

Separate ownership from practical control

The sentence “you own the website” is too broad to evaluate the project.

A website combines legal rights, licensed components, accounts, billing relationships, data, and administrative access.

Domain

Confirm:

who is listed as the registrant;
whose registrar account contains the domain;
who receives renewal notices;
who controls DNS;
who pays renewal fees;
what the transfer path is if the provider relationship ends.

ICANN describes the registrant as the person or entity registering the domain through a registrar relationship. See ICANN’s information for domain registrants.

Hosting and deployment

Confirm:

who owns or controls the hosting account;
who pays recurring fees;
who can publish or roll back a deployment;
whether the site can be moved;
what happens when a support plan ends.

CMS and connected accounts

Check owner or admin access for:

the content-management system;
analytics;
Search Console;
Tag Manager;
advertising pixels, when applicable;
form, calendar, CRM, and email services.

The proposal should explain how the business retains or receives access to its data and operational accounts if a contractor account is removed or the relationship ends.

Content, design, and code

Separate:

client-provided materials;
provider-created copy and design;
custom code;
stock images;
fonts;
themes and plugins;
APIs and software licenses;
AI-assisted assets;
source files or repository access.

Payment does not automatically transfer every copyright interest in every protected project element.

Under U.S. copyright law, copyright initially vests in the author except where the law provides otherwise, including qualifying works made for hire. Copyright ownership may later be transferred. A transfer of copyright ownership, other than by operation of law, generally requires a written document signed by the owner of the rights being transferred or an authorized agent. Work-made-for-hire treatment is limited to the circumstances established by law. See the U.S. Copyright Office materials on copyright ownership and transfer and work made for hire.

The signed documents should explain:

what is assigned;
what is licensed;
what remains provider-owned;
what belongs to a third party;
what the client may modify or move;
whether source files or a repository are included.

Material intellectual-property questions should be reviewed by a qualified U.S. attorney.

Business Control Map

Business Control Map
Asset or account	Rights or license	Admin access	Billing owner	Transfer or export path
Domain	Registrant and control terms documented	Client-controlled registrar admin	Business-controlled payment method	EPP/auth code and transfer instructions
Hosting	Account plan and service terms documented	Client owner/admin access	Named billing owner	Backup, export, or migration path
CMS	License or plan terms documented	Owner/admin role available	Named payer if paid	Content export plus admin handoff
Analytics	Business property/account access documented	Admin or owner role available	Named payer if paid	User/admin transfer and export settings
Search Console	Verified property access documented	Owner-level access available	Not normally applicable	Owner access can be granted or removed
Code or repository	Source rights follow the signed agreement	Repository admin or equivalent access	Named payer if private/paid	Clone/export plus credential handoff
Images, fonts, and plugins	License terms and reuse rights documented	Source files, keys, or admin access as applicable	Named payer for paid assets	Original files, license records, and keys

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.”

Define “done” before launch
Check	Responsible party	Method and evidence	Pass condition	Blocks launch
Form and notifications	Builder plus client recipient	Submit test cases; verify inbox or CRM delivery	Required fields, confirmation, and routing work	Yes if this is the primary lead path
Mobile behavior	Frontend owner	Test agreed widths and priority devices	No clipped content, broken layout, or unusable controls	Yes on priority pages
Redirects	Migration owner	Test priority old URLs and crawl mapped routes	Mapped URLs reach intended destinations with agreed status codes	Yes if replacing an existing site
Analytics	Analytics owner	Use debug or realtime view for agreed events	Required events and conversions record as specified	Conditional on launch scope
Accessibility review	Implementation owner	Keyboard, labels, contrast, zoom, and semantic review	Agreed critical issues are resolved or documented	Yes for agreed critical failures
Credential handoff	Provider plus client account owner	Access checklist and client login confirmation	Client can administer every agreed account and asset	Yes

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:

What risk does this model create?
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.

Compare normalized proposals
Dimension	Proposal A	Source A	Proposal B	Source B	Proposal C	Source C
Business objective	Audience / outcome / next step	Page / clause	Audience / outcome / next step	Page / clause	Audience / outcome / next step	Page / clause
Deliverables and exclusions	Included + excluded deliverables	Page / clause	Included + excluded deliverables	Page / clause	Included + excluded deliverables	Page / clause
Responsibilities and client inputs	Provider duties + client inputs	Page / clause	Provider duties + client inputs	Page / clause	Provider duties + client inputs	Page / clause
Dependencies and recurring costs	Vendors + recurring fees	Page / clause	Vendors + recurring fees	Page / clause	Vendors + recurring fees	Page / clause
Control and access	Accounts + admin + transfer	Page / clause	Accounts + admin + transfer	Page / clause	Accounts + admin + transfer	Page / clause
Acceptance and launch	Tests + launch condition	Page / clause	Tests + launch condition	Page / clause	Tests + launch condition	Page / clause
Support	Defects / revisions / maintenance	Page / clause	Defects / revisions / maintenance	Page / clause	Defects / revisions / maintenance	Page / clause
Unresolved risk	Open assumptions / unanswered items	Page / clause	Open assumptions / unanswered items	Page / clause	Open assumptions / unanswered items	Page / clause

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

Assign a risk label only after reviewing the Ledger

GREEN — DEFINED: the item is defined or explicitly excluded.
YELLOW — CLARIFICATION REQUIRED: a question remains, but the exposure can be evaluated.
RED — MATERIAL RISK UNRESOLVED: the issue may affect cost, launch, control, or the ability to change providers.

Color must never carry the meaning by itself. Pair it with the text label.

Decision gate for a red item

Before signing, handle the item in one of three ways:

clarify it and add the resolution to the documents;
explicitly exclude it from the engagement;
knowingly accept the operational or financial consequences.

A universal weighted score is unnecessary. The importance of each item depends on the project.

A lower-cost proposal can be correct when its exclusions match the client’s plan. A higher-cost proposal is not automatically complete.

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:

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

The goal is not to eliminate every risk.

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

Review the proposal before the project becomes a rebuild

ProAI Expert reviews website proposals for:

scope and exclusions;
content responsibility;
access and control;
rights and licenses;
integrations and dependencies;
acceptance evidence;
launch;
support.

The review helps identify what is included, where it is documented, which questions remain open, and where the business retains risk. It does not replace legal review of the contract and does not guarantee provider quality or project results.

Review My Website Proposal

Review My Website Proposal