Choose a web development company by checking how it turns your brief into verifiable work, acceptance criteria and a usable handover. Give shortlisted providers the same scope, then compare their evidence and responsibilities. An attractive portfolio or a low total does not, by itself, explain what your team will receive.
A practical selection process needs three small documents: a shared brief, an evidence sheet and a handover list. The framework below helps you build them without running an elaborate procurement exercise.
Give every candidate the same starting point
Before discussing technology, describe the business task. Proposals become difficult to compare when one provider assumes a brochure site and another includes a CMS, bilingual content and lead routing.
Your initial brief should cover:
- The audience and the action visitors should take.
- Required page types and prepared content.
- Languages and who approves each version.
- What staff must edit without a developer.
- Where inquiries go and any external connections.
- An existing website and URLs that must be preserved.
- A target date, budget boundary and which constraint can move.
Ask each provider to restate its understanding and identify exclusions. A useful proposal may challenge your assumptions, but it should explain why. A different idea is easier to evaluate when the resulting trade-off is visible.
If the budget is still unclear, the company website cost guide helps separate implementation and operating items before you compare totals.
Verify the contribution behind a portfolio entry
When you find a relevant project, ask what the provider actually delivered. Building a complete site, improving its interface and maintaining it are different contributions. Any of them may be relevant, but a screenshot cannot establish the difference.
The documented KWDStore Optimization project, for example, concerns interface and user-experience improvements, WebP imagery, SEO and blog presentation, article covers and marketing material. That scope does not establish that PIXELSAA built the whole store or achieved an unreported percentage improvement. Look for the same precision when reviewing any supplier's work.
Use this evidence ladder:
| Evidence offered | What it establishes | Useful follow-up |
|---|---|---|
| A screenshot or project name | There is work being presented | Ask for the provider's specific role |
| A defined contribution | What the provider says it delivered | Request a relevant functional example |
| A demonstration or reviewable deliverable | How part of the solution works | Connect it to your own requirements |
Some work cannot be shown publicly. An authorized example or an explanation with private information removed can still be useful. You do not need another customer's credentials or records to evaluate a provider.
Industry similarity is only one signal. A supplier that can demonstrate the editing, inquiry or content workflow you need may offer more relevant evidence than a visually similar site with an unexplained implementation.
Replace the general sales call with a small demonstration
Select one task close to your project and ask to see it on an appropriate example. A short agenda can reveal more than a long list of framework names.
Visitor journey: Find a service, understand it and reach the inquiry form on a phone. Observe navigation and clarity, as well as presentation.
Editor journey: Change a title and image, preview the result and publish it. If you need two languages, ask how incomplete translations are handled.
Failure path: What happens when a required email address is missing? How does a staff member verify that a valid inquiry arrived? Any test submission should happen in an agreed environment, rather than on another customer's live site without permission.
Handover: Ask to see the structure of operating instructions or a delivery checklist, with other customers' details removed.
Record what was demonstrated separately from what was promised. Your goal is a concrete example of the provider's approach, not a free prototype of the whole project.
Ask what the quality claims actually include
Search readiness
Ask for specific tasks and responsibilities: content, page titles, URLs, technical checks and release review. Google warns that nobody can guarantee a number-one ranking in its results. Treat a promised position as a claim to question, not evidence of implementation quality. Source: Google's guidance on hiring an SEO.
For a more detailed scope discussion, use the company website search and SEO guide. It helps separate work a provider can deliver from traffic or sales outcomes it cannot simply promise.
Usability and accessibility
Try keyboard navigation, read form labels and inspect error messages. Ask which pages and devices the review covers. W3C describes its initial accessibility checks as a starting point, not a comprehensive evaluation. Source: W3C Easy Checks.
A successful demonstration is therefore useful evidence, but not acceptance of an entire site. Agree on examples covering your key journeys and the evidence to be supplied at delivery.
Security verification
Ask how permissions, inputs, uploaded files where applicable, recovery and updates are handled. You do not need to recite vulnerability names. You need to understand what will be checked and how responsibility is assigned.
OWASP ASVS can inform specific security verification requirements during procurement. Mentioning the standard is not proof that an assessment has occurred or that every requirement is met. Source: OWASP ASVS.
Use a weighted evidence sheet, with mandatory gates
The following is an original editorial decision aid. It is not an agency ranking, research dataset or validated predictor of project success. Adjust the weights before scoring proposals so the criteria do not shift to favour the first presentation you liked.
Use three evidence levels:
- 0: No clear answer, or an unresolved contradiction.
- 1: A specific written answer, with supporting delivery or acceptance evidence still missing.
- 2: An answer supported by a relevant demonstration or reviewable document.
| Criterion | Suggested weight | Evidence to record |
|---|---|---|
| Scope and exclusions | 25 | Defined outputs and a shared brief |
| Relevant work and actual contribution | 20 | Explained or demonstrated delivery |
| Handover and ongoing editability | 20 | Accounts, files and your access |
| Testing and acceptance | 20 | Test cases and expected evidence |
| Communication and change control | 15 | Owner and approval process |
Criterion points = weight × evidence level ÷ 2. The result is for your internal comparison of this project, based on the material available. It is not a general public rating of the supplier.
Set mandatory gates before adding up points: a clear deliverable, understood account access and a way to retrieve your content. If a fundamental requirement remains unresolved, ask for clarification before appointing the provider, regardless of the total score. “Unknown” belongs in the evidence sheet; it should not silently become a positive assumption.
Keep a short note beside each score. If someone asks why one supplier scored higher, you should be able to point to an answer or demonstration rather than a personal impression.
Check what happens after launch
Separate completion of the agreed scope, correction of a defect and a new feature request. Ask how each is recorded, who determines the category and how additional work is approved before it starts.
A handover list can cover, where applicable:
- Domain and hosting accounts, including renewal responsibility.
- Administration accounts and the permissions your staff need.
- Content, files and data you can export.
- Source code and design files included in the agreement, with relevant licence limits.
- Backup and recovery instructions, plus the person responsible.
- Support channels, scope and agreed availability.
A hosted platform and a custom implementation may have different source-code and export boundaries. Understand the selected arrangement before buying. Do not assume around-the-clock support or unlimited changes unless those are explicitly offered.
For a distributed project, also record the review channel, the person who can approve work and how decisions are written down. This is a practical coordination question; it does not require the provider to claim an office in your city.
A supplier response request you can reuse
Please review the attached website brief and explain your understanding of the scope, deliverables and exclusions. Include a relevant project with your exact contribution, your approach to content editing, testing and acceptance, and a handover list. Identify operating and support charges, how changes are approved, and which items still need information or a decision.
Complete the missing answers before comparing providers on scope, evidence, responsibilities and budget. Apply the same questions to PIXELSAA's web development service, then talk through your website brief and delivery expectations with us. Share the criteria that matter most to your business so the discussion begins with the work you need.
