How to Compare Website Proposals: A 12-Criterion Scorecard

Comparing website proposals by total price alone can make substantially different scopes look like the same service. One proposal may include content entry, integration testing, and post-launch support, while another leaves those responsibilities with the client. The figures may appear comparable, but the work being purchased is not.

Start by checking that every agency is responding to the same requirement. Then assess scope, deliverables, responsibilities, access and handover, technical quality, timing, and post-launch services in one scorecard. Do not assume that an item is included when the proposal omits it or describes it only as a broad promise. Ask for written clarification.

The 12-criterion scorecard in this guide is not designed to rank suppliers by the lowest price. It helps a buyer understand which differences in scope, evidence, and delivery risk sit behind each price.

Create a Common Basis Before Comparing Proposals

Proposals become difficult to compare when agencies receive different information. One supplier may estimate a ten-page corporate website, another may include multiple languages and integrations, and a third may assume responsibility for content production. Those totals are answers to different questions.

Send every potential supplier the same project summary. Define the intended users, pages and modules, content readiness, languages, integrations, desired launch date, and expected support model. If this work is not complete, use our guide to preparing a website requirements document before requesting comparable proposals.

Ask every supplier to separate three lists:

• Work included in the fee and delivery plan
• Optional or separately priced work
• Explicit exclusions and assumptions

Without this separation, phrases such as “corporate website”, “SEO-ready platform”, or “multilingual support” can represent very different deliverables.

Score Evidence from 0 to 3

Instead of marking each criterion only as present or absent, score the clarity and evidence behind it:

This model does not calculate the “best agency”. A proposal can achieve a high total score and still fail a requirement that is essential to your project, such as source handover, a payment integration, or a defined support response. Add your own importance label—critical, important, or optional—to every criterion.

12 Criteria for Comparing Website Proposals

1. Business Objective and Definition of Success

A proposal should explain the business outcome the website is intended to support, not only the pages that will be produced. This may involve building confidence in the brand, generating qualified enquiries, explaining products, supporting transactions, handling bookings, or improving a customer operation.

Ask:

• Which business objective shaped the proposed solution?
• Which audience groups and user tasks were considered?
• How will delivery and success be assessed?

“A modern and impressive website” is not a definition of success. The proposal should connect design and technical decisions to something users need to understand or complete.

2. Project Scope and Named Deliverables

The proposal should list pages, modules, functions, and handover items. “Website design and development” does not tell you how many original page templates will be designed, which forms and modules will be built, which fields editors can manage, or which documents will be provided.

Kumsal Ajans proposals separate the purpose and overall scope from services, design and development, page and module lists, platform decisions, compatibility, testing, launch, training, and handover. Look for a similar level of clarity across every proposal you compare.

Useful evidence may include a detailed scope table, page list, module list, sample sitemap, or deliverables register.

3. Exclusions and Assumptions

A strong proposal makes excluded work visible as well as included work. Copywriting, product entry, translation, stock media, video production, data migration, domains, hosting, email configuration, third-party licences, or usage fees may sit outside the stated price.

Review assumptions separately. A proposal may assume that content will be approved by a particular date, the existing system will permit data export, or a third-party provider will grant suitable API access. It should explain what happens to timing and fees when an assumption proves false.

When the proposal is unclear, ask: “Which assumptions in this scope could lead to an additional fee or schedule change?”

4. Content Production, Entry, and Migration

Designing a page, writing its copy, and entering content into a platform are three different tasks. A proposal should state how many pages, products, services, or content records the agency will enter. It should also identify who supplies text, photography, video, documents, and translations, in which format, and by what date.

For a redesign, ask whether migration means basic copying or includes editing, restructuring, and quality control. Preserving important URLs, preparing redirects, and transferring metadata may also be separate deliverables.

If content is not bounded by a quantity or content type, do not assume that competing proposals include the same workload.

5. Design Process, Revisions, and Approval Boundaries

Revision terms should define the stage and type of change, not only a number. The phrase “unlimited revisions” remains ambiguous unless the proposal explains where that commitment begins and ends.

At Kumsal Ajans, design revisions are unlimited until the design is approved. Approval is the boundary. Returning to an approved design or requesting a new page, feature, or change in scope is not treated as part of the same revision commitment; it is assessed as additional work.

Check whether each proposal answers these questions:

• During which stages can revisions be requested?
• Who consolidates and submits stakeholder feedback?
• What makes a design formally approved?
• How is a return to an approved stage handled?
• How does the supplier distinguish a design correction from a scope change?

Without those definitions, “two rounds” and “unlimited” cannot be compared fairly.

6. Technical Platform and Content Management Scope

A technology label alone does not explain what the buyer can operate. The proposal should describe what editors can change, how user roles are managed, whether the platform can support new page or content types, and who remains responsible for updates and maintenance.

For a project-specific content management platform, ask:

• Which content can the client edit without developer support?
• Are user roles and permissions available?
• Are translated pages managed as connected locale versions?
• How are forms, media, redirects, and SEO fields controlled?
• Are there licence, dependency, or update costs?
• Can the project be handed to another team with the required files and documentation?

Do not score a platform simply as “custom” or “off the shelf”. Suitability, operability, handover, and long-term responsibility matter more than the label.

7. Integrations and Third-Party Costs

CRM, ERP, payment, booking, shipping, messaging, mapping, or email services should be defined individually. Naming a service does not explain its data flow or who is responsible for each part.

The proposal should state:

• Which system sends and receives each type of data?
• Is the integration one-way or two-way?
• Who provides test accounts and technical access?
• Who pays API, licence, messaging, transaction, or usage fees?
• Is adaptation included if the third-party service changes?
• When an integration fails, which team investigates which component?

Kumsal Ajans separates the service, data flow, scope, responsibilities, and third-party fees. If another proposal says only that an integration is “included”, request a written breakdown.

8. Domain, Hosting, Accounts, Design Files, and Source Access

The proposal and contract should show which assets and accounts the client can access at handover. This section should list deliverables, licence exceptions, and transfer methods without making unsupported legal conclusions.

At Kumsal Ajans, client-owned assets are handed over according to the proposal and contract once project fees and applicable third-party costs have been completed:

• Project-specific source code may be transferred through a Git repository, an archive, or infrastructure nominated by the client.
• Reusable agency libraries, licensed components, and third-party software remain subject to their respective terms.
• Figma, Adobe, or similar working files are provided when they form part of the agreed scope.
• If a domain is registered to the client, access is returned or confirmed; if it is held in an agency account, the appropriate transfer process is followed.
• Administrator access is transferred for client-owned servers. For managed or shared hosting, project files, backups, and relevant account details are provided according to the agreed service.
• Content management, DNS, SSL, CDN, analytics, and other service access is documented in a secure handover register.

Ask for a handover document listing services, licences, renewal dates, and subscriptions the client must continue. Seek appropriate legal advice where the effect of intellectual-property or contract clauses needs specialist interpretation.

9. SEO, Accessibility, Performance, and Measurement

Terms such as “SEO-friendly”, “fast”, or “accessible” need measurable deliverables. SEO scope may include title and description controls, crawlable links, sitemaps, robots directives, canonical handling, redirects, structured data, image alternatives, and measurement accounts.

Google Search Essentials identifies crawlable links and helpful, people-first content among its key practices. It also makes clear that meeting technical requirements and best practices does not guarantee crawling, indexing, or rankings. A proposal should therefore list the work it will perform rather than promise a guaranteed first-page position.

Accessibility scope can identify the target standard, keyboard operation, contrast, form labels, text alternatives, and testing responsibility. The W3C accessibility planning guidance recommends integrating objectives and responsibilities into project planning.

For performance, ask which page types, devices, tools, and acceptance conditions will be used. The proposal should also explain who owns analytics, Search Console, Tag Manager, or advertising accounts and how access will be managed after launch.

10. Testing, Launch, Backups, and Handover Documents

Finishing design and development does not automatically make a website ready for launch. The proposal should identify which browsers and devices will be checked, how forms will be tested, who approves integration scenarios, and how defects are recorded and resolved.

For higher-risk web applications, a primary standard such as the OWASP Application Security Verification Standard can help structure security requirements and verification scope. Not every corporate website needs the same test depth; the proposal should match verification to the system's functions and risk.

Check that the launch plan answers:

• Who gives final approval to publish?
• How will migration and redirects be managed?
• Is there a backup and rollback plan?
• Will forms, analytics, and integrations be checked again in production?
• When will platform training and handover documents be provided?
• Where will defects, credentials, and service inventories be recorded?

11. Schedule, Team Roles, and Client Responsibilities

A useful schedule is more than a start date and launch date. It separates discovery, information architecture, design, approval, development, content entry, testing, and launch into milestones.

The plan should include dates when the client must provide copy, translations, brand assets, integration access, and consolidated feedback. If decision-makers are not identified, conflicting stakeholder feedback can create repeated work across design and development.

Kumsal Ajans proposals show project stages, delivery milestones, and client and agency responsibilities in separate sections. Training is also bounded by duration, method, topic, and participant count—for example, a defined online content-management session for an agreed number of users.

12. Warranty, Maintenance, Support, and Additional Development

These terms describe different services and should not be merged into one vague post-launch promise:

• Warranty: Correction of software defects within the delivered and approved scope, subject to the stated period and conditions. New requirements, user error, content changes, or third-party service issues may be excluded.
• Maintenance: Agreed work on platform continuity, components, security, compatibility, updates, backups, monitoring, or performance.
• Support: Help with usage questions, access problems, or operational needs through a stated channel, response time, and any monthly allowance.
• Additional development: A new page, module, feature, integration, or workflow requested after approval of the original scope and assessed separately.

“Twelve months of support” is not sufficiently precise on its own. Ask which channels are available, whether hours are limited, what response targets apply, how warranty differs from support, and how new work is estimated.

The 12-Criterion Website Proposal Scorecard

Complete the table for every proposal. Beside each score, record the relevant proposal page, supporting document, or unanswered question.

After calculating the total, review critical requirements separately. If payment processing is essential, for example, a low integration score may make a proposal unsuitable even when its total appears strong.

A Clearly Labelled Comparison Scenario

The following is not a real client case. It is a fictional scenario designed only to demonstrate the decision method.

Imagine that a mid-sized manufacturer receives two proposals for a corporate website redesign. Proposal A has a lower initial fee, but does not define content entry, integration data flows, source handover, or the support model. Proposal B costs more, but separately lists page and module scope, content quantities, testing, training, handover documents, and maintenance options.

The useful question is not simply, “Which proposal is cheaper?” Ask instead:

• How would Proposal A's total change when the missing items are added?
• Which proposal makes the buyer's own workload clearer?
• How will critical accounts and source assets be transferred?
• Which option makes third-party fees and post-launch needs more visible?
• Which unresolved assumptions could become change requests after signing?

Proposal A may become the better option after it clarifies those points in writing. Proposal B is not automatically correct merely because it is more detailed. The scorecard is intended to make the evidence behind the decision visible, not to favour one supplier in advance.

Final Questions to Ask Before Signing

Collect unresolved points in one list and send the same questions to every shortlisted supplier:

1. Which work is explicitly excluded from this proposal?
2. Which content, access, decisions, and approvals must the client provide?
3. What are the stage and approval boundaries for design revisions?
4. Which licences and usage fees are payable to third parties?
5. How will source code, design files, accounts, and handover documents be transferred?
6. What are the test and acceptance criteria?
7. How are warranty, maintenance, support, and new development separated?
8. Which client or third-party dependencies affect the schedule?

Ask for important verbal explanations to be added to the proposal or contract documentation. Where a clause has a material legal or commercial effect, obtain review from an appropriate specialist.

Conclusion: Read Price Together with Scope and Evidence

The purpose of comparing website proposals is not to choose the longest document or the highest score. It is to understand what will be delivered, which responsibilities the buyer retains, and which post-launch needs could create additional cost or operational risk.

First align every proposal to the same requirements document. Then score the 12 criteria by evidence level, review critical requirements separately, and resolve ambiguity through written questions. This lets you interpret price alongside scope, operating responsibility, and risk.

If you would like to define your project scope or request a comparable proposal, review the Kumsal Ajans web design service.

Frequently Asked Questions

Why is the lowest website proposal not always the best fit?

Proposals may not include the same pages, content, integrations, testing, training, handover, or support. A lower initial fee can change when missing work is added. Compare the price with included deliverables, exclusions, and buyer responsibilities.

Is “unlimited revisions” sufficient wording in a proposal?

No. The proposal should define the stage to which unlimited revisions apply and the event that ends that commitment. At Kumsal Ajans, design revisions are unlimited until design approval; returning to an approved design or changing scope is assessed as additional work.

Are source code and design files delivered for every project?

Handover depends on the proposal, contract, licences, and project structure. The transfer method for project-specific source, exclusions for reusable libraries and third-party software, and whether working design files are included should be confirmed in writing before approval.

What is the difference between warranty, maintenance, and technical support?

Warranty covers defects within the approved delivery scope. Maintenance addresses agreed continuity work such as updates, backups, and monitoring. Support helps with usage or operational needs. New pages, modules, and features are additional development.

Should the supplier with the highest score always be selected?

No. The scorecard supports judgement; it does not replace it. If a critical integration, handover, or support requirement remains weak, that issue should be assessed separately even when the total score is high.