Website Vendor Proposal Comparison Scorecard for Small Businesses
A line-by-line scorecard for comparing website proposals by ownership, scope, accessibility, performance, security, measurement, support, and exit terms.
Two website proposals can quote similar prices while describing very different outcomes. One may include content migration, accessibility review, analytics, hosting, backups, support, and a documented handoff. Another may include only a template setup, leaving the owner to supply content, connect systems, and solve problems after launch.
Use this scorecard to put every vendor on the same page before you choose. Send each vendor the same project inventory, ask for written answers, and score only what the proposal or contract actually commits to deliver.
What matters most
The best proposal is not automatically the lowest price or the longest feature list. It is the one that defines a suitable outcome, assigns responsibilities clearly, protects business ownership, and gives you a practical way to verify the work.
Before requesting estimates, write down:
- the business goal and primary customer action;
- required pages, locations, services, languages, and content to migrate;
- forms, payments, scheduling, CRM, email, maps, reviews, analytics, or other integrations;
- who supplies copy, photography, brand assets, legal language, and approvals;
- launch deadline and any event driving it;
- current domain, DNS, hosting, email, analytics, search, and advertising accounts;
- internal staff who will update the site after launch;
- expected maintenance, reporting, and support.
Ask vendors to identify assumptions and exclusions against that same inventory. A price based on six pages cannot be compared fairly with one based on thirty pages and a content migration.
How to score website proposals
Use a 0–3 scale for every item: 0 = omitted, 1 = vague statement, 2 = defined deliverable, and 3 = defined deliverable with acceptance method, owner, and timing. Mark any item that is mandatory regardless of total score.
1. Scope and content
| Question | Evidence to request |
|---|---|
| What is being built? | Page and template inventory, features, integrations, responsive states, and browser/device support |
| Who creates content? | Number of copy rounds, word or page limits, photography, image licensing, migration, metadata, and approvals |
| What is excluded? | Explicit list of out-of-scope work, allowance limits, hourly rates, and change-order process |
| How is completion judged? | Review stages, acceptance criteria, testing period, defect process, and launch authorization |
Request a sitemap or page list with each proposal. Phrases such as “up to ten pages” should explain what counts as a page, whether legal pages are included, and what happens when the final inventory changes.
2. Ownership and portability
The business should know who owns and controls every essential asset. Record the proposed account owner for:
- domain registration and registrar login;
- authoritative DNS;
- hosting, deployment, and backups;
- source code or site export;
- written content, original design files, photos, fonts, plugins, and licenses;
- form submissions and customer data;
- analytics, tag management, Search Console, advertising, maps, and business profiles;
- transactional email, CRM, scheduling, and payment integrations.
Ask what happens if the relationship ends. The proposal should state what the business receives, in what format, within what time, at what cost, and what help is available for transition. A vendor may have legitimate license restrictions on third-party themes, fonts, or software; those restrictions should be disclosed before purchase.
ICANN advises registrants to maintain accurate registration contact information and understand their registrar relationship. Even when a vendor administers the domain, the business should have a documented ownership and recovery path.
3. Design, mobile use, and accessibility
Ask how the vendor will test navigation, forms, buttons, headings, keyboard access, focus, contrast, text resizing, alternative text, errors, and common mobile screen sizes. Request the accessibility target by name—for example, the applicable WCAG 2.2 level—and the testing method.
No vendor can responsibly promise that a site will be “100% ADA compliant” forever based only on an automated scanner. W3C explains that WCAG provides testable success criteria, while conformance evaluation requires judgment and can involve both automated and human testing. The proposal should define what is checked, what standard is targeted, what limitations remain, and how future content is handled.
Score higher when the vendor provides sample deliverables such as an issue log, keyboard walkthrough, form-error test, content guidance, and a process for correcting confirmed barriers.
4. Performance and technical quality
Replace “fast” or “optimized” with a test plan. Ask:
- which representative pages and devices will be tested;
- whether measurements are lab tests, real-user field data, or both;
- which Core Web Vitals or other metrics will be reported;
- what test date, tool version, and conditions will be recorded;
- how third-party scripts and customer-supplied media affect the target;
- what happens when a result misses the agreed threshold.
Google's web.dev documentation identifies Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift as the current Core Web Vitals and explains their “good” thresholds at the 75th percentile of page loads. A single desktop screenshot is not proof that all users or pages meet those thresholds.
Also request basics such as HTTPS, canonical URLs, redirects, status codes, structured data where relevant, XML sitemap, robots controls, semantic headings, image dimensions, error pages, and form-delivery testing.
5. Security, privacy, and recovery
The Federal Trade Commission advises small businesses to define security expectations when choosing vendors and to verify that providers follow through. Ask the website vendor to document:
- software update responsibilities and timing;
- administrator access, multifactor authentication, and offboarding;
- secret and API-key handling;
- backup frequency, retention, restoration responsibility, and restore testing;
- logging, monitoring, incident notification, and escalation;
- form-data collection, retention, deletion, and third-party sharing;
- privacy, cookie, payment, health, or industry-specific responsibilities;
- subcontractors and critical service providers.
“Daily backups” is incomplete without location, retention, restore access, and a tested recovery procedure. Score the recovery plan, not the existence of a checkbox.
6. Analytics, leads, and search visibility
Define the customer actions that matter: calls, forms, appointments, purchases, directions, downloads, or qualified inquiries. Ask who configures analytics, consent settings, event definitions, filters, dashboards, and account ownership.
For search work, request deliverables rather than ranking guarantees. Useful items may include crawl and index controls, redirect mapping, titles and descriptions, local-business consistency, structured data, search-console setup, and a post-launch indexing check. No vendor controls Google's rankings, and traffic or ranking alone does not establish lead quality or revenue.
For forms and calls, test the complete path from a public page to the real recipient. Document validation, spam handling, confirmation messages, notification delivery, storage, privacy, mobile use, and a backup contact method. A form that displays “success” but never reaches the business is not successful.
7. Maintenance, support, and total cost
Create a three-year cost table that includes setup, design, content, hosting, licenses, domains, email services, maintenance, support, analytics, integrations, accessibility work, backups, and likely change requests.
Ask each vendor to state:
- included monthly work and what is billed separately;
- support channel, coverage hours, first-response target, and emergency definition;
- update, backup, monitoring, reporting, and review schedule;
- annual price changes or usage-based costs;
- content-editing turnaround and limits;
- cancellation notice, export cost, and transition assistance.
A low build price paired with proprietary lock-in or expensive routine changes can cost more over time. A higher managed price may be reasonable when the continuing deliverables are specific and valuable. The scorecard makes that tradeoff visible.
What this scorecard cannot decide
A numeric score cannot determine whether you trust a team, whether its design style fits your brand, or whether its process suits your staff. It also cannot verify a claim that the vendor will not demonstrate.
References and portfolios show past work, not a guaranteed result for your project. Contact references with similar scope and ask what changed, how problems were handled, and whether the site was easy to operate after launch.
The scorecard is not legal advice. Have qualified counsel review ownership, privacy, accessibility, intellectual-property, liability, and termination terms when the business risk warrants it.
Put the scorecard into practice
Give each vendor the same written inventory and a copy of the questions. Score the written response before a sales call, then use the call to resolve gaps. Afterward, ask the vendor to add important promises to the proposal or contract; meeting notes are weaker than agreed deliverables.
Choose a small set of non-negotiables, such as business ownership of the domain, a working export path, form-delivery testing, named accessibility target, account handoff, and backup restoration procedure. Do not let a high total score erase a zero on a critical requirement.
Finally, turn the winning proposal into a launch and handoff checklist. Assign an owner and acceptance method to every deliverable so the same scorecard that helped you buy the site also helps you receive it.
Mendola.Tech can review competing proposals, build a neutral scope, or provide a managed website plan with ownership, maintenance, measurement, and handoff terms documented up front.
Official references
- Web Content Accessibility Guidelines (WCAG) 2.2 — World Wide Web Consortium; accessed 2026-08-13. Provides the current W3C Recommendation and testable accessibility success criteria.
- WCAG overview — W3C Web Accessibility Initiative; accessed 2026-08-13. Explains the guidelines, supporting documents, and conformance context.
- Cybersecurity for Small Business — Federal Trade Commission; accessed 2026-08-13. Provides small-business security and vendor-management guidance.
- Cybersecurity for small business: Hiring a web host — Federal Trade Commission; accessed 2026-08-13. Suggests questions about security, updates, access, backups, and service-provider practices.
- Information for domain name registrants — Internet Corporation for Assigned Names and Numbers; accessed 2026-08-13. Explains registrant responsibilities and domain-management resources.
- Web Vitals — Google/web.dev; accessed 2026-08-13. Defines the current Core Web Vitals and their user-experience focus.
