Before hiring a web designer, verify five things: what they actually built, whether they can handle your main customer task, what the quote includes, who controls the accounts, and how you will accept the finished work. Ask for evidence you can open, try or confirm yourself.
A good-looking portfolio is a useful starting point. It leaves several buying questions unanswered. A designer may have created the visual direction while someone else built the site. A working demo may never have served a real customer. Neither arrangement is a problem when it is explained clearly.
This guide is for a business choosing someone to build or redesign its website. The checklist below is a practical purchasing method, not a certification scheme or a guarantee that a project will succeed.
1. Check the work and the person's role
Ask for two relevant examples. Two is a manageable starting point, not an industry rule. A supplier building a quote catalogue should be able to discuss a comparable customer journey; an attractive restaurant homepage alone will not answer that question.
For each example, ask:
- Can I open the live site? If it is unavailable or confidential, what can you show with permission?
- When did you work on it, and which parts did you personally handle?
- Was this a client delivery, a team contribution, a template adaptation or a concept demo?
- What constraint shaped the work, and what would you change now?
- Who looks after it today?
Open the site on your phone and try its main route. A public link proves that a site exists. It does not establish who built it, who owns it or how much business it produced. A footer credit is another clue, not conclusive proof of authorship.
For a shortlisted supplier, ask permission to speak with a past client. Use a business contact you can independently confirm, rather than treating a forwarded testimonial as verification. Ask what was delivered, how changes were handled, whether the agreed accounts and files arrived, and what happened when something broke. Do not ask for that client's private messages, invoices or customer data.
A newer designer may have no client reference yet. Clearly labelled concept work, a candid explanation of their role and a smaller agreed first stage can still give you something to assess. Missing experience is a limitation to price into your decision; invented experience is a reason to stop.
2. Ask them to demonstrate your main customer task
Give each shortlisted candidate the same short brief. For example: “A buyer needs to find a product, understand the minimum order and send us a quote request from a phone.” This is an illustrative task, not a claim about a particular client.
Ask the designer to walk through an existing relevant example or explain how they would implement that route. Watch what happens after the first screen: Can the buyer find the information? Does the contact action preserve the product reference? What happens if a required field is missing? Where does the request arrive?
Use a test environment and an inbox you control for any submission test. Do not place real orders or send trial enquiries to an unrelated business. If a working sample requires new production work, agree a small paid scope, its ownership and its acceptance conditions first. A free complete website is not a sensible screening requirement.
Include basic checks that match the job: phone layout, keyboard navigation, visible focus, understandable field labels and useful error messages. Ask what will be tested before launch and what evidence you will receive. W3C's Easy Checks can help you start, but passing a quick review does not establish comprehensive accessibility.
Technical vocabulary is optional in this conversation. The candidate should be able to explain the customer's task, the tradeoffs and what you will be able to verify.
3. Compare written scope before comparing prices
Send the same brief to everyone quoting. List your pages, languages, content, product data, integrations and target launch conditions. If you have an existing site, say what must stay available and which addresses need to keep working.
Turn broad promises into items you can accept:
| Area | Ask the proposal to specify | Evidence at acceptance |
|---|---|---|
| Pages and content | Named pages, languages, who writes and supplies images | The agreed pages contain approved content |
| Products and functions | Data quantity, fields, search, quotes or checkout, exclusions | A representative customer task works with agreed data |
| Revisions and changes | Included review rounds, response duties, how extra work is quoted | Requested changes are either included or separately approved |
| Launch and migration | Domain setup, old addresses, forms and any email dependencies | Agreed routes work on the production domain |
| Ongoing work | Renewal items, support period, response arrangements and exclusions | A named contact and a written responsibility list |
| Handover | Accounts, editable files or exports, licences and instructions | You can sign in and perform the agreed management tasks |
Keep design, content creation, migration and ongoing support visible as separate responsibilities, even if sold together. A lower quote may cover fewer pages, require you to supply finished text or leave product entry to your staff. That can be a reasonable purchase when it matches your capacity.
For budgeting, use the business website cost guide. For renewal and support questions, use the maintenance guide. The comparison here is about what each supplier will deliver, rather than an assumed “correct” price.
4. Confirm account control and the exit path
Ask the supplier to show how access will work before you commit. “You own the website” is too broad to settle the practical details.
For the domain, confirm the registration account, registrant details, renewal contact and recovery route. For hosting or a website platform, confirm whose account holds the site, who pays recurring bills and what management access your business receives. Use individual invitations where supported, with access appropriate to the work, rather than sharing your main password.
Collaboration and ownership are separate arrangements. For example, Shopify distinguishes access to a merchant-owned store from a store ownership transfer. Ask which arrangement applies to your project and when any transfer will happen. In Google Search Console, owners can manage users and permissions; seeing a traffic screenshot is not the same as controlling the property.
Also list the material you will receive or be licensed to use: text, images, design files, custom code, themes, fonts and extensions, as applicable. Ask which items have separate licences or subscriptions and whether those remain usable after the supplier leaves. Do not assume payment automatically gives you every source file or the underlying platform software; have the deliverables and usage terms written down.
A managed subscription can be a valid choice. Find out what remains available if you cancel, which content or data can be exported, what a move would require, and whether there is an exit charge. Exporting content may not reproduce the design or every function elsewhere. These are purchasing questions to resolve while you still have a choice.
At handover, sign in through your own business account. Try the agreed editing or publishing task and locate the renewal information. A password list alone does not demonstrate a usable handover.
5. Agree what each milestone proves
Tie project reviews and payment milestones to named deliverables. The number of stages and payment split depend on the job; a deposit by itself does not tell you whether a supplier is reliable.
A practical sequence could be an approved page plan, a working test version with your content, production acceptance, then handover. Write down who approves each stage, what must work, how defects are reported and how new requests change the price or date. Distinguish a broken agreed feature from a new feature you thought of later.
Keep search promises equally concrete. Ask what “SEO included” means: page titles, indexability checks, redirects for changed addresses, a sitemap, or ongoing research and content work? These are different deliverables. Google's hiring guidance recommends checking past work and references, and warns against guaranteed first-place rankings.
A published site, a page indexed by Google, a search visit, an enquiry and a sale are different events. If a candidate claims a result, ask what was measured, over which period and what they actually contributed. They can decline to share private client data; the claimed result then remains unverified. A screenshot or a promise does not close that gap.
Pause when a candidate repeatedly avoids explaining their role, cannot turn the quote into a scope, or leaves your account access and cancellation route unresolved. One broken link in an old portfolio is a question to investigate, not enough on its own to label someone dishonest.
6. A shortlist message you can reuse
Send this after describing your business and the task your website needs to support:
Please share two relevant examples and explain your role in each. I'd like to walk through the main customer task on a phone, compare a written scope, and confirm who will control the domain, platform and search accounts. Please also list the ongoing charges, handover items and cancellation or transfer arrangements. If appropriate, may I speak with a past client with their permission?
Keep the replies beside the same brief. Mark each point as confirmed, unanswered or excluded. Before choosing, resolve the unanswered items that would prevent launch, routine use or a future handover. You do not need to become a developer to ask for that evidence.
Is an attractive portfolio enough?
It shows visual judgement. Check the candidate's actual contribution, a relevant working task and the proposed delivery arrangement as well.
Should I reject anyone who uses a template or AI tools?
Ask what was adapted, what is licensed, how the output was checked and who will maintain it. Tool choice alone does not prove competence or poor work. The delivered result and the agreed responsibilities are what you can evaluate.
Can a small paid first stage reduce uncertainty?
It can make the candidate's working process observable, provided the scope, payment, rights and acceptance are clear. It does not guarantee that a larger project will go well.
If you are still deciding what needs fixing before contacting suppliers, start with the business website self-audit checklist. It gives you a more useful brief than “make the site look modern.”
