How to compare website proposals when every agency scopes differently

Three website proposals can respond to the same brief and describe three materially different projects.

One may include stakeholder planning, information architecture, wireframes, content support, migration, testing and launch coordination. Another may begin with supplied designs and content. A third may leave integrations or search migration until later. Their page counts can look similar. Their prices can be far apart.

That does not automatically make one proposal inflated or another incomplete. Agencies use different methods, assumptions, platforms, team structures and risk tolerances.

The buyer’s task is to make the proposals comparable before selecting one.

Headline price only becomes meaningful after scope, assumptions, exclusions, responsibilities and risk have been normalised.

The best proposal is not necessarily the largest. It is the smallest credible engagement that can meet the requirement without concealing material work or uncertainty.

The short answer: compare ten dimensions

Assess each proposal across:

• Recommended pathway and assumptions
• Deliverables by phase
• Functional scope and boundaries
• User experience, design and content
• Platform, integrations and data
• Content and search migration
• Governance, approvals and change
• Testing, deployment and release
• Warranty, maintenance, support and enhancements
• Total investment, third-party costs and ownership

Create one comparison sheet. Copy each agency’s actual commitment into the relevant row. Mark “not stated” where the proposal is silent. Do not infer an inclusion from a capability statement or case study.

Then ask the agencies to clarify material differences in writing. The goal is not to force identical methods. It is to understand what each investment buys and which risks remain with the client.

1. Is the agency recommending the right starting pathway?

Before comparing deliverables, check whether each agency is solving the same problem.

A straightforward, well-defined corporate website may suit a template-led or focused custom project. A complex platform involving portals, integrations, business rules, large migrations or unresolved governance may require paid Discovery before implementation can be responsibly fixed.

The proposal should explain why its pathway fits the known requirements and uncertainty.

Look for:

• The website’s business and user outcomes
• Priority audiences and actions
• Confirmed requirements
• Material assumptions
• Unresolved questions
• Dependencies on client teams or third parties
• The boundary between planning and implementation

A separate Discovery phase should not be a reflex. It is credible when unknowns could change platform choice, architecture, scope, programme, cost or viability. An incomplete brief for an otherwise simple website may only need targeted clarification.

Similarly, a fixed implementation proposal should not imply certainty it does not have. If consequential questions remain, find out whether the agency has included contingency, excluded the work or assumed a particular answer.

2. Compare deliverables, not process headings

Two proposals may both list “Discovery, UX, design, development and testing” while promising very different outputs.

Translate each phase into tangible deliverables and decisions.

Planning and Discovery

Possible outputs include stakeholder workshops, user research, current-state analysis, functional requirements, a content model, technical assessment, integration mapping, RAID register, governance model and implementation roadmap.

Do not assume all of these are included because the word Discovery appears. Confirm the number and purpose of sessions, participants, outputs, review process and whether the result is decision-ready for implementation.

Information architecture and UX

Confirm whether the proposal includes a sitemap, audience journeys, content hierarchy, wireframes, prototypes and mobile considerations. Ask which page templates or journeys will be wireframed and how many consolidated revision rounds are included.

Visual design

Identify the number of initial concepts, page templates, component states, responsive breakpoints and revision rounds. A homepage design plus style direction is not the same as a complete component system across all critical templates.

Development

Ask which templates, components, content types, forms, roles and functions are included. Confirm what is configured from established capability, what is customised and what requires bespoke development.

Quality assurance and launch

Confirm the testing types, supported browsers and devices, accessibility scope, security activities, performance checks, user acceptance responsibilities, deployment planning, tracking validation and post-release checks.

The proposal should make the completion evidence clear. “Website development” is too broad to compare on its own.

3. Normalise functional scope and exclusions

Page count is a weak proxy for complexity.

A 20-page marketing website with standard forms can be simpler than a five-page experience containing account access, a product selector, quotation logic and a CRM workflow. Compare the system behaviour behind the screens.

Build a functional list covering:

• Page and content types
• Navigation, search and filtering
• Forms and routing
• Locations, people, products or resources
• Ecommerce and payment rules
• Accounts, roles and permissions
• Calculators, selectors or configurators
• Integrations and automation
• Administration and reporting
• Non-functional requirements

For each item, record whether it is included, excluded, assumed standard, provisional or subject to later scope.

Exclusions are not inherently negative. A clear exclusion can protect both parties. The risk lies in an important activity being absent, ambiguous or discovered only after implementation begins.

Pay particular attention to phrases such as “where possible”, “standard functionality”, “basic integration”, “client to arrange” or “to be confirmed”. Ask what those boundaries mean in the specific project.

4. Separate user experience, visual design and content

These disciplines influence one another but are not interchangeable.

User experience

UX work defines structure, journeys, hierarchy, interactions and usability. Ask how the agency will understand users and validate important decisions.

Visual design

UI work expresses the brand and creates a coherent responsive component system. Confirm whether the proposal begins from a template, adapts an existing design system or creates a focused custom interface.

Content

Content is frequently the largest client-side dependency. Confirm:

• Who audits the current content
• Who decides what to retain, merge, rewrite or remove
• Who writes and approves copy
• Who supplies and licenses imagery
• Who enters content into the CMS
• How many pages or items are included
• What happens when content arrives late

“Client supplies content” can mean the client supplies final, approved copy in the required structure before design. It can also mean the agency will migrate existing content with limited editing. Those are different commitments.

If content quality will materially shape the design and conversion journey, it should not remain an unresolved afterthought.

5. Compare platform, integration and data commitments

A platform logo does not define the solution.

WordPress, Shopify, BigCommerce and other systems can be implemented in many ways. Ask why the platform fits the requirement, who owns the licences, how content is managed, what extensions are required and what maintenance responsibilities continue after launch.

For integrations, compare more than the names of systems. The proposal should state, at the appropriate level:

• Business outcome
• Data moving between systems
• Source of truth
• Direction and frequency
• Authentication and access dependencies
• Mapping and validation
• Failure handling and monitoring
• Testing environments
• Ongoing ownership

If the systems or APIs have not been examined, the proposal should not imply feasibility is proven. A responsible agency may recommend paid Discovery or technical validation before fixing implementation scope.

Third-party software introduces its own terms, limits, roadmaps and costs. Confirm who contracts with each provider and who supports the integration when one side changes.

6. Treat migration as its own workstream

Migration can include pages, documents, products, customer records, orders, redirects, metadata, analytics, media and permissions. “Content migration included” is not enough.

Ask for quantities, quality assumptions, transformation rules, validation, client responsibilities and exception handling.

Search migration deserves explicit scope when URLs, information architecture or domains change. Google’s site-move guidance recommends mapping old URLs to new destinations, implementing redirects, testing and monitoring. A redesign proposal that changes URLs but excludes redirect planning transfers a material risk to the buyer.

Confirm whether the agency will:

• Crawl and inventory the current site
• Review traffic, rankings and backlinks
• Create and implement a redirect map
• Preserve important metadata and structured content
• Test staging controls and production indexability
• Validate analytics and Search Console after launch
• Monitor the transition

Do not assume a general SEO capability statement means SEO migration is included in the implementation fee.

7. Compare governance, approvals and change control

Website delivery depends on client decisions as much as agency production.

The proposal should identify:

• Day-to-day contacts
• Project sponsor and decision-makers
• Meeting and reporting cadence
• Approval stages
• Consolidated feedback process
• Included revision rounds
• Dependency and risk management
• Change-request process
• Consequence of delayed content, access or approval

Revision counts need context. Two consolidated rounds can be adequate when stakeholders are aligned and feedback is governed. Five rounds can still fail when every stakeholder comments independently and earlier decisions reopen.

Ask what constitutes a revision versus a scope change. Adjusting an approved colour treatment differs from adding a new customer portal. The proposal should explain how changes are assessed, approved, priced and scheduled.

Also confirm who has authority to accept decisions. A project can appear on time while approvals remain unresolved. Governance should expose that risk early.

8. Examine testing and release evidence

“Fully tested” is not a test plan.

Compare the specified scope across:

• Functional and regression testing
• Responsive layout and supported browsers or devices
• Forms, integrations and error handling
• Content, links and media
• Accessibility
• Performance
• Security
• Analytics and conversion tracking
• User acceptance testing
• Deployment and rollback
• Post-launch verification

Accessibility scope should name the intended standard, level and evaluation method where compliance is required. WCAG 2.2 is a testable W3C Recommendation, but a proposal should not promise conformance through a generic plugin or a single automated scan. The W3C’s conformance evaluation guidance describes a structured evaluation process.

Security should also be integrated into the delivery lifecycle. Australia’s Secure by Design foundations emphasise quality assurance and ongoing testing rather than a final cosmetic check.

Ask who fixes defects found during agency QA and client UAT, when the site is ready to launch, and which known issues can be accepted into a later backlog.

9. Distinguish warranty, maintenance, support and enhancements

These terms are often grouped together even though they fund different responsibilities.

Functional warranty

A functional warranty corrects eligible defects in the delivered implementation under defined conditions and for a defined period. It is not a fund for new requirements or third-party changes.

The applicable functional-warranty period, eligibility and exclusions should be stated in the current proposal and governing agreement. Confirm the governing wording immediately before using any exact commercial term in a proposal or publication.

Maintenance

Maintenance covers routine platform care such as updates, patching, checks and other agreed preventive work. It continues beyond a short delivery warranty under a separate arrangement.

Support

Support covers operational assistance, troubleshooting, investigation, release coordination and agreed response arrangements. The model may be retained or scheduled from flexible hours, subject to current commercial terms.

Enhancements

Enhancements add or change capability: new pages, integrations, workflows, UX improvements or campaigns. They are new work even when requested during a warranty period.

Compare what each agency includes after launch, the response commitment, the charging model and whether unused capacity expires. Do not treat an undefined promise of “ongoing support” as equivalent to a documented support model.

10. Calculate total investment and ownership

Bring the complete cost view together:

• Agency fees by phase
• Client internal time
• Content, photography, video or data preparation
• SEO migration
• Platform, plugin, application and font licences
• Hosting and infrastructure
• Payment gateway and transaction costs
• Accessibility, privacy or security specialist work
• Integration-vendor fees
• Ongoing maintenance, support and optimisation
• Contingency for genuinely unresolved risk

Emote does not sell, resell or directly provide hosting infrastructure. Emote may advise on hosting requirements, recommend and coordinate with a suitable partner, or work with the client’s appropriate existing host. The client normally contracts and pays the host directly. A proposal should make that responsibility and third-party cost visible.

Also compare ownership and access. Confirm who owns the domain, hosting account, platform tenant, source code or theme rights, design files, content, analytics properties, advertising accounts and licences, subject to the governing contract and third-party terms.

Payment schedules should be compared with delivery stages and acceptance evidence, not merely the number of instalments.

Red flags worth clarifying

A red flag is a prompt for a question, not an automatic disqualification.

Clarify proposals that contain:

• A fixed price despite material unresolved functionality or integrations
• A large contingency with no explanation
• Important services shown only as optional after the headline total
• Undefined “standard” functions
• No content or migration responsibility
• No named testing or acceptance process
• Accessibility, security or search guarantees without method
• Unlimited revisions with no governance
• A platform recommendation without requirement rationale
• Ongoing support with no model or responsibility boundary
• Third-party costs and ownership left unstated
• A timetable that assumes instant client content and approvals

Strong proposals make assumptions visible. They do not need to predict every future detail, but they should show how uncertainty and change will be handled.

A fair evaluation process

Use this sequence:

• Confirm the brief: outcomes, audiences, requirements, constraints and known unknowns.
• Separate mandatory and optional needs: avoid rewarding unnecessary scope.
• Normalise the ten dimensions: copy actual commitments into one matrix.
• Issue one clarification round: give each agency the same material questions.
• Evaluate evidence: relevant public work, team capability, methodology and references.
• Assess working fit: communication, challenge, transparency and governance.
• Compare risk-adjusted investment: price plus omissions, dependencies and retained client risk.
• Document the decision: record why the selected pathway is credible.

For complex programs, the most responsible next procurement step may be paid Discovery rather than choosing an implementation quote. Discovery should resolve the consequential questions and create a better basis for implementation investment.

Emote’s public Primary Dental case study shows why visible page scope can be misleading. The work involved more than 60 locations, content consistency, multiple integrations, search migration, transition and security advisory. That is public proof of complex delivery considerations, not a benchmark price or a universal process for every website.

Frequently asked questions

Should we choose the cheapest website proposal?

Choose the proposal that offers the strongest fit and risk-adjusted value. The lowest price can be appropriate when its scope and assumptions meet the need. It can be misleading when material work sits outside the total.

Can we compare proposals by page count?

Page count is one input. Template types, functionality, content, integrations, migration, governance and non-functional requirements usually explain more of the effort and risk.

Should every website proposal include Discovery?

Every project needs enough planning to make sound decisions. A separate paid Discovery engagement is warranted only when consequential uncertainty prevents responsible implementation scope.

What is the difference between an assumption and an exclusion?

An assumption states the condition under which scope and price remain valid. An exclusion states work the proposal does not include. Both should be specific and testable.

Does a fixed price guarantee there will be no change requests?

No. A fixed price applies to a defined scope and assumptions. New requirements, changed dependencies or incorrect assumptions can still require written change control.

Who should evaluate technical sections?

Include an appropriately experienced technical stakeholder or independent adviser for material architecture, integration, security, data and hosting decisions. Do not ask procurement or marketing to infer technical risk alone.

Compare the project behind the price

A proposal is a model of the future engagement. It shows what the agency understands, what it will deliver, what it expects from the client and how both parties will manage risk.

Compare that model, not only the total at the bottom of the page.

Normalise the pathway, deliverables, functionality, UX, content, platform, integration, migration, governance, testing, after-launch responsibility and total ownership cost. Ask the same material questions. Then select the smallest credible engagement that can meet the requirement.

Explore Emote’s Websites and eCommerce and Digital Transformation capabilities.

If you have a website brief and want to understand the appropriate starting pathway, book an initial meeting with Emote. The initial conversation will clarify known requirements and material unknowns; detailed strategy, architecture and scope remain part of an agreed engagement where warranted.