Small Business Website: Vendor Selection Checklist for U.S. Buyers

Define the purchase before comparing providers

A website proposal is difficult to evaluate when each provider is pricing a different product. One may include research, information architecture, copy support, analytics, accessibility review, and launch QA. Another may be quoting visual design and page assembly only. The totals are not comparable until the expected outcome and operating scope are comparable.

Start with the decision the website must improve. That may be qualified inquiries, booked appointments, ecommerce revenue, product activation, or a cleaner sales evaluation path. Record the current baseline, the audiences that matter, the systems the site must connect to, and the people who will approve content. This brief becomes the reference point for every proposal conversation.

• Primary audience, valuable action, and current conversion baseline
• Required pages, content responsibilities, integrations, migration, and languages
• Accessibility, performance, analytics, privacy, security, and SEO acceptance criteria
• Launch deadline, approval owners, internal capacity, and post-launch operating model

Separate capability evidence from presentation

A polished sales deck proves that a provider can make a polished sales deck. It does not prove that the team can diagnose your business problem, preserve search equity, build accessible interactions, migrate content, or support production after launch. Ask for evidence that matches the risk in your project.

Review two or three relevant examples in detail. Look for the original constraint, the team's role, the decisions they made, the implementation they owned, and the measured result. When client data is confidential, process artifacts, testing evidence, architecture decisions, or release documentation can still demonstrate mature work without invented performance claims.

• Named responsibilities rather than a vague agency-wide capability list
• Examples similar in complexity, workflow, audience, or operating constraint
• Evidence of mobile, accessibility, form, analytics, performance, and release QA
• Clear distinction between work the provider created and work supplied by the client

Inspect the process where projects usually fail

Most delivery risk appears between disciplines: strategy to copy, copy to design, design to development, development to content entry, and launch to ownership. A credible process explains how decisions move across those boundaries, who approves them, and what happens when input arrives late or requirements change.

Ask to see the expected meeting cadence, decision log, content workflow, staging review, change-control rule, browser/device coverage, and launch checklist. The provider should be able to describe failure handling without improvising. This is especially important for forms, CRM routing, ecommerce payments, redirects, tracking, and third-party scripts because a visually correct page can still fail operationally.

Make ownership and portability explicit

Ownership should not be implied. Confirm who controls the domain, DNS, hosting, source code, design files, analytics, tag manager, search accounts, CMS administrator access, paid plugins, font licenses, media licenses, and third-party subscriptions. Record what transfers at final payment and what remains licensed.

Also define portability. If the relationship ends, can another qualified team operate the site using standard access and documentation? Proprietary components are not automatically a problem, but their maintenance cost, export path, replacement risk, and dependency on the original provider should be visible before signing.

• Client-controlled accounts for domain, analytics, search, CRM, and critical vendors
• Repository, build, environment, backup, deployment, and recovery access
• License inventory with renewal owner and expected annual cost
• Handoff package, documentation, training, warranty period, and support terms

Use a weighted scorecard, not a price ranking

Price matters, but it should be evaluated beside business fit and delivery risk. Create a scorecard before final presentations so the criteria do not change based on the most persuasive salesperson. Weight each category according to the project: strategic understanding, relevant evidence, technical approach, content plan, measurement, ownership, accessibility, support, timeline, and total cost.

Require every evaluator to score independently before discussion. Large differences expose assumptions worth resolving. A provider with the lowest estimate may be the correct choice for a tightly defined implementation. A broader team may be more efficient when the work requires research, copy, complex integrations, migration, and ongoing optimization. The scorecard makes that tradeoff visible.

Contract around acceptance, change, and recovery

The final agreement should connect deliverables to acceptance criteria. Define review windows, revision limits, dependencies, payment milestones, out-of-scope rates, termination rights, confidentiality, data handling, accessibility expectations, warranty coverage, and the process for production incidents. Avoid language that promises rankings, conversion lifts, or legal compliance without evidence and shared responsibilities.

Before work starts, confirm the baseline measurement plan and preserve the current site, content, analytics definitions, and URL inventory. The best vendor decision is not the one with the most features. It is the one that creates a clear path from current evidence to a maintainable result while keeping ownership and risk visible.