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.
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.
A website project may involve several documents:
The names vary. The important question is whether the documents describe the same project.
If the sales process promised:
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:
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.
The seven areas below describe the substance of the proposed engagement.
| 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.
A question list helps you interview a provider. A risk ledger helps you evaluate what the documents actually resolve.
| 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.
Record the facts, assets, approvals, accounts, or decisions the client must provide—and the date or project stage when they are needed.
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.
Record:
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.
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 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.
Page count is only one dimension.
Review five groups.
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.
| 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 |
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.
| 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.
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.
Confirm:
ICANN describes the registrant as the person or entity registering the domain through a registrar relationship. See ICANN’s information for domain registrants.
Confirm:
Check owner or admin access for:
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.
Separate:
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:
Material intellectual-property questions should be reviewed by a qualified U.S. attorney.
| 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.
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:
“Calendar integration included” is incomplete.
A clearer scope identifies:
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.
Launch is an event. Acceptance is a decision that the delivered work meets the agreed scope.
Possible acceptance areas include:
hreflang when applicable;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.”
| 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.
These terms should not be interchangeable.
A change within an agreed deliverable before approval.
New or changed scope.
Delivered behavior that does not meet the agreed result or acceptance criteria.
Post-launch work such as:
The documents should explain:
There is no universal correct support period. The problem is an undefined one.
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:
Ask:
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.
Material warnings include:
Other items require context rather than automatic rejection:
Ask:
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 resolved risk, not the number of bullets.
| 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.
Color must never carry the meaning by itself. Pair it with the text label.
Before signing, handle the item in one of three ways:
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.
Repeat costs can appear when content, mobile behavior, integrations, migration, access, licenses, verification, or support were not:
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.
Before signing:
The goal is not to eliminate every risk.
The goal is to prevent important risk from hiding inside an assumption.
ProAI Expert reviews website proposals for:
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
{% include insights/related-decisions.html insight_id=page.insight_id lang=page.lang %}