Choose your supplier
A good question. A clearer proposal.
Before choosing a web designer, get clear on the job, the working relationship and what stays with your business.
Leave with questions you can use, a way to interpret the answers and the gaps to resolve before you agree.
Read the guideA way through the work
One shared brief. Four things to agree.
Compare the proposed work against the same job, then agree who decides and how completion will be checked.
Customer task
Who needs the site, and what should it help them do?
Agreed scope
What work is included, excluded or still to discuss?
Named responsibilities
Who supplies, checks, approves and maintains it?
Delivery evidence
What will be demonstrated before you accept the work?
One chapter at a time
Questions to ask before hiring a web designer
Start with the same job
A portfolio shows what a supplier has made. Your conversation needs to show how they would approach your task. Give each supplier the same short brief: who the website serves, what those people need to do, what already works and what the business can maintain.
Ask how they would investigate an unclear answer. Leave room to keep the existing site, make a bounded repair or stage a smaller project. You do not need to choose a platform before the problem is understood.
Ten questions worth asking
01. What customer task are we designing around?
Listen for a named audience, a useful task and the next action. “A professional presence” needs more detail to become a brief.
If it stays vague: supply a real example and ask the supplier to explain the route through the site.
02. What is included, and what is outside this scope?
Clarify pages or templates, functionality, content, connections, review rounds and exclusions. A page count alone does not describe the work.
If it stays vague: request a written scope, including what would need a separate agreement.
03. Who writes, supplies, checks and approves the content?
Name a role at each handoff, including factual review and permission to use images. A schedule needs those inputs as well as design time.
If it stays vague: name the missing owner before agreeing dates.
04. What will you check before launch?
Ask about specific customer journeys, mobile and keyboard use, agreed accessibility expectations and technical checks. The answer should state the checks and their limits.
If it stays vague: ask for the acceptance checklist and who reviews the evidence. A general assurance is not a test result.
05. What does the schedule depend on?
Content, account access, approvals and third parties can affect delivery. Agree who supplies each dependency and how delays are handled.
If it stays vague: ask what happens if an input arrives late and who updates the schedule.
06. How do changes get agreed?
Confirm who can approve a change, how its effect on scope, cost and timing is recorded, and when the additional work begins.
If it stays vague: ask to see the change process before the project starts.
07. What can our team edit after handover?
Look for a demonstrated routine update, suitable permissions, training and a clear account of any supplier-only work.
If it stays vague: choose one everyday edit, such as changing a service area, and ask how your team would do it.
08. Which accounts, files and exports will we receive?
Confirm account and billing owners, delivered formats, dependencies and an exit route. Ask what another supplier would need to take over.
If it stays vague: request an itemised handover list. Keep passwords and credentials outside the brief.
09. What costs and support continue after launch?
Separate recurring services from the build quote. Identify the payer, renewal owner, included support, response expectations and chargeable work.
If it stays vague: ask what happens when a service renews, a tool changes or you need an update.
10. Who does the work, and who is our contact?
Make delivery roles, specialist partners, the decision owner and the contact route visible. Several contributors still need clear responsibility.
If it stays vague: confirm who resolves an issue that crosses two people's work.
Access, authorship and permissions
Account access, authorship and contractual permissions are separate questions. A login does not settle rights to source, images, fonts or other assets. Ask which agreements or licences apply, what can be transferred and which permissions need to be confirmed.
Record the documents or agreements to check. Obtain appropriate advice when rights are uncertain; a handover checklist cannot resolve them by itself.
Keep the next conversation small
Before agreement, record the shared scope, exclusions, responsibilities, acceptance checks, dependencies, change process, recurring costs and exit arrangements. You can start with the four groups below and add questions where the project needs them.
An unanswered item is a next conversation, not automatically a reason to reject a supplier. Ask for the missing detail, agree who will provide it and carry it into the written proposal.
Fictional worked example
Rowan Heating · fictional example
Rowan wants homeowners to understand its service area and request a visit. One proposal describes “a modern five-page website”. Another names who supplies the service copy, what happens after an enquiry, how the team updates coverage and what will be demonstrated at handover.
The second answer makes more work visible. It does not prove the supplier will deliver or that the proposal is better in every respect. Rowan can ask both suppliers to price the same essentials and explain their assumptions. If writing or a booking connection is excluded, that difference belongs in the comparison.
Something you can keep
Your supplier conversation
Record what you heard, what supports it and what still needs agreement. Keep credentials and private customer details out of these notes.
Use the fields here or print this guide from your browser. Still Matter does not submit or save these notes. Copy or print what you need before closing this page. Keep private details and credentials elsewhere.