Most advice about hiring a web designer is about how to judge their work. That is the easy part, and it is not where projects go wrong. They go wrong over things nobody discussed: who was supposed to write the copy, whether the photographs were licensed or bought, what "finished" meant, and who could log in to the domain when the site needed moving two years later.
None of that requires technical knowledge to sort out. It requires asking, before you sign, a set of questions that a good provider will answer readily and often has answered in writing already.
Work out what you need before you ask anyone to quote
A provider cannot price what you have not described, and a proposal written against a vague brief will be vague in the same places. Before you contact anyone, write down:
- The business outcome. Not "a new website" -- more enquiries, fewer phone calls asking the same question, bookings taken without a call back.
- Who it is for, and what you want them to do when they arrive.
- What has to connect to it: booking, payments, mailing list, till system, whatever you already run the business on.
- What already exists -- domain, logo, photographs, copy, an old site -- and who can actually log in to each of them today.
- Who writes the words. This is the single most common reason a project stalls, and the answer is very often "nobody has thought about it".
- Who decides. One person, by name, with the authority to approve.
- When it matters, and what happens if that date slips.
- How you want to run it afterwards: yourself, with help, or not at all.
That list is most of a brief. It is also the thing that lets you compare two proposals, because both of them are now answering the same question.
Choose the kind of provider, then the provider
A freelancer, a small studio, a full-service agency, a specialist in one platform and a managed subscription are five different arrangements, not five sizes of the same one. They differ in what happens when the person who built your site is unavailable, in how much of the work is yours to run afterwards, and in what you are paying for each month.
None is better in general. The one worth choosing is the one whose answers to the next section you find convincing.
Build a shortlist on relevance, not polish
Look for work that resembles the problem you have, not work that is attractive. A portfolio is evidence of taste and of what a provider chooses to show. It is weak evidence of how a project is run, which is what you are actually buying.
Worth weighing:
- Work that solves a comparable problem, even if it looks nothing like what you want.
- Whether they can explain a tradeoff they made, and why.
- Sites they built that are still maintained, rather than launched and abandoned.
- What happens if the individual doing the work is ill or leaves.
- Whether they raise accessibility and performance before you do.
- How they normally take access, and how they hand it back.
Awards and review-platform ratings tell you about marketing and about other people's projects. Neither is proof of fit for yours.
The questions worth asking
Ask all of these. A provider who finds them tiresome is telling you something useful.
Scope. What problem are you designing for? Which page types and deliverables are included, and what is expressly excluded? What assumptions, if they turn out wrong, would change the price or the date?
Platform. Which platform, host, theme, plugins and services, and why those for this project? Which of them carry a recurring licence, and what stops working if one is not renewed? Who handles backups, updates, monitoring and recovery -- and is that included or sold separately?
Accounts. Which accounts will be created, and in whose name will each one live? Can you work through an account of your own rather than holding ours? Who controls recovery, multi-factor authentication, billing and DNS? If we ended this tomorrow, what would you need to remove, and would the site keep working?
Content and rights. Who supplies and approves the copy, the photographs, the fonts and the graphics? Which materials are custom, which pre-existing, which stock or open-source? What rights do we receive in each, on what payment conditions? Are source and design files included?
Delivery. What are the milestones? How are revisions handled, and how many are included? What counts as acceptance? Which browsers and devices are tested, and what accessibility checking is in scope? What is the launch plan, and what is the plan if launch goes wrong?
Afterwards. What support is included, for how long? What needs a maintenance plan? How do recurring services renew and how are they cancelled? If we part company, what do we receive, how long does it take, and what does it cost?
Compare proposals on the same rows
| What to look for | A clear answer Specific enough to hold someone to | Ask again Not a red flag on its own -- an unfinished answer |
|---|---|---|
| Scope and exclusions | Names the page types and templates included, and says what is expressly not included. | "A modern, professional website" with no list of what is being built. |
| Who supplies content | Says who writes the copy, who takes the photographs, and what happens if they are late. | Silent on content, which is the most common reason a project stalls. |
| Platform and components | Names the platform, theme, plugins and services, and says why they suit this project. | Names a platform and nothing else, or declines to say why. |
| Recurring costs This is the one most often discovered in year two. | Lists every licence and subscription, who pays it, and what breaks if one lapses. | A single monthly figure with no breakdown. |
| Accounts and access | Says which accounts will be created, in whose name, and how your provider gets access. | Assumes the provider will hold the accounts, without saying so directly. |
| Rights in the work See the ownership page for why that sentence is rarely accurate on its own. | Separates custom work from pre-existing, stock and open-source material, and says what you receive in each. | "You own everything." |
| Acceptance and revisions | Defines what finished means, how many rounds of changes are included, and what a change request costs. | Leaves acceptance to be agreed later, usually alongside the final invoice. |
| Accessibility There is no single technical bar a provider can simply certify against. | States which standard and level is being worked to, and what will be tested. | Promises the site will be "ADA compliant" without naming anything testable. |
| After launch | Says what support is included, for how long, and what needs a maintenance plan. | "We'll look after you." |
| Handoff | Lists what you receive if the relationship ends, and what assistance costs. | Not addressed, because nobody expects the relationship to end when it begins. |
A caution marks something that commonly surprises people later.
Evidence: Editorial assessment Last verified
Put every proposal against the same rows. The point is not to catch anyone out -- a good provider will answer all of this readily, and often has the answers written down already. A proposal that cannot be compared on these terms is usually not hiding something, it is just not finished.
A vague answer is usually not concealment. It is usually a proposal that was written quickly, by someone who has answered these questions before and assumes you know the answers. Ask again. What you learn from the second answer -- how readily it comes, how specific it is -- is worth more than the first one was.
Keep the accounts your business cannot afford to lose
The pattern that causes the least trouble is simple: your business creates and owns the accounts, and your provider gets named access at the level the work needs, which you can withdraw without changing a password that four other people also use.
| Account or asset | Your business The role to hold yourself | Your provider The least access that lets the work happen |
|---|---|---|
| Domain registrar Everything else depends on it, including email. | Account owner, with recovery and billing visible to you | Delegated access where the registrar offers it |
| DNS Registration and DNS hosting can sit with different companies. | Able to see every record and to change them | Operational access for the records the work touches |
| Website platform or hosting | Owner or primary owner | Administrator or collaborator at the level the work needs |
| Analytics Measurement history is the part you cannot reconstruct later. | Administrator | Named user at the level they need |
| Search Console | Verified owner | Delegated owner or user |
| Business profile listing | Primary owner | Manager, and only while the work runs |
| Business email Mail that stops arriving is harder to notice than a site that stops loading. | Administrator | No access unless a specific task needs it |
| Payment processor Treat any request for broader access here as a question, not a formality. | Account owner | The minimum the integration requires, if any |
A caution marks something that commonly surprises people later.
Evidence: Editorial assessment Last verified
This is a recommended starting pattern, not a rule any platform enforces. Some platforms do not offer separate roles at all, and a few of these rows will not apply to your project. Where a platform cannot separate them, that is worth knowing before you sign rather than afterwards.
This is achievable on the platforms we checked. Search Console lets a verified owner grant delegated ownership without handing over verification. Analytics identifies users by their own account rather than a shared login. Shopify lets a merchant authorise a partner through a collaborator account, scope it to particular apps, remove it permanently, and have it lapse on its own after ninety days without a login -- and documents a workflow where a partner builds a store and transfers ownership when it is ready.
It is not universal, and the page does not claim it is. Squarespace treats domain ownership and site ownership as separate things, and any collaborator at any permission level can start moving a domain away, though only the designated registrar contact receives the authorisation code. Wix documents two different handovers: transferring the site itself to another Wix account, where a Premium site's plan and domain can go with it, or transferring a copy while the original stays in the sending account, with contacts, orders and invoices not copied. Agree which one you will receive. Ask how it works on the platform you are actually going to use.
Caution: Caution: If a provider needs to hold an account you would rather own, that can be a legitimate arrangement. What makes it safe is writing down who controls it, how you recover it, and what happens to it if either of you walks away.
The matrix above is about the project you are starting. The nine areas below are the wider audit -- what your business controls today, before anyone new is given access to it. Worth running once before you hire, so you know what you are handing over.
Website Ownership Check
Nine areas to establish before a provider touches any of them.
-
Area 01. Domain registration
-
Area 02. DNS control
-
Area 03. Website platform or hosting account
-
Area 04. Website files and portability
-
Area 05. Business email
-
Area 06. Analytics and Search Console
-
Area 07. Copy, photography, graphics and design
-
Area 08. Customer and operational data
-
Area 09. Cancellation, export and handoff
What the agreement should address
This is a list of topics, not a contract, and not a substitute for having a lawyer read the one you are offered.
- Who the parties are, and what is being built
- Deliverables, assumptions and exclusions
- What each side is responsible for supplying, and by when
- Milestones, fees, deposits and the payment schedule
- How change requests are priced and approved
- What acceptance means, in terms you could point at
- Accessibility scope and what will be tested
- Custom work, pre-existing materials, third-party licences and who holds which rights
- Whether the provider may show the work publicly
- Support, maintenance and how recurring services renew
- Termination, and what is delivered on the way out
- Confidentiality, data handling and privacy responsibilities
On rights specifically: copyright ordinarily begins with whoever created the work, and a transfer of copyright ownership generally must be documented in a writing signed by the owner of the rights being conveyed or that owner's authorized agent. An exclusive licence can itself qualify as a transfer; a nonexclusive licence does not. "Work made for hire" is not a phrase that can simply be added to an agreement -- it has statutory requirements, including, for commissioned work, that the work fall within one of nine listed categories and that the parties expressly agree in a signed writing.
Legal information, not legal advice: Not legal advice: This describes general U.S. copyright rules so you know which questions to ask, and lists topics an agreement should cover. It is not legal advice, it is not a contract template, and it is not a substitute for having a lawyer look at an agreement that matters to your business.
On accessibility, specifically
Ask what standard is being worked to and what will be tested. The Department of Justice has said that businesses open to the public have flexibility in how they comply with the ADA and that it has no regulation setting out detailed technical standards -- so no provider can certify compliance against a single published bar, and a proposal promising it is overstating what is available to promise.
What a provider can say is which guidelines they are working to and at what level. WCAG 2.2 is the current W3C Recommendation, with conformance levels A, AA and AAA, claimed for whole pages and complete processes rather than for parts of a page. "The homepage will be accessible" is therefore not a conformance claim, and is worth turning into one.
Things worth a second conversation
None of these proves bad faith. Each is worth asking about directly, and the answer usually settles it.
- The domain must stay in the provider's own account, with no written arrangement for transferring it
- One shared password instead of named accounts, on a platform that offers named accounts
- No written scope, or a scope with no exclusions
- A single recurring figure that is never broken down
- "You own everything", without a list of what everything includes
- No explanation of what you would receive if you left
- Guaranteed rankings, traffic or revenue
- Reluctance to explain why this platform
- Final payment due on a date rather than on anything you could point at and call finished
- A maintenance plan with no defined response time, exclusions or term -- and note that a response time is the time to acknowledge you, not the time to fix anything, so it says nothing about resolution time, which is what happens next
Before you accept the site
Check these yourself, before the final invoice rather than after it.
- The content and design are the ones you approved.
- It works on a phone, and it can be used with a keyboard alone.
- Every form arrives somewhere you can see, and you have tested one.
- The site loads over HTTPS on the address you want people to use.
- Analytics and Search Console are under your control, not only reporting into your inbox.
- If this replaces an old site, the old addresses go somewhere sensible.
- You can log in to the domain and the platform yourself, today.
- A backup exists, and somebody has explained how it would be restored.
- The privacy and terms pages match what the site actually does.
- You have been shown how to make the changes you expect to make.
- You have a written list of everything that renews, when, and for how much.
What handoff should include
Ask for this as a list, and tick it off:
- Registrar and DNS access
- Platform and hosting access, in your name
- Files, database or repository, where the agreement includes them
- Design and source files, where the agreement includes them
- An inventory of licensed assets and whose account holds each
- Analytics, Search Console and tag-manager access
- How email and form delivery are configured
- Backup and restore instructions
- How to deploy a change, if that applies
- A list of every service the site depends on
- A renewal calendar
- Provider access removed, or reduced to what is still needed
The last one is easy to forget and is the one that matters six months later. Check it yourself rather than asking whether it has been done.