Hiring someone to build your website can be surprisingly difficult.
Not because there are too few options.
Because there are too many.
Freelancers. Agencies. Design studios. Developers. Marketing companies. Website subscription services. Template specialists. People who design. People who code. People who do both.
And nearly everyone can show you a portfolio, tell you they build responsive websites, mention SEO, and promise something professional.
That still leaves you with the harder question:
How do you know who should build yours?
I don't think the answer is finding the provider who gives the most impressive sales presentation.
And I don't think you need to become an expert in web development before you hire one.
You need to understand enough about how they approach the work to decide whether you trust them with the decisions your website requires.
So rather than interviewing someone for the right buzzwords, I would ask questions that reveal how they think.
What do you need to understand about my business before you start?
This might be the most useful question on the list.
Listen carefully to the answer.
A web designer does not need to become an expert in your industry before they can build a good website.
But they should need to understand more than your logo colors and a list of services.
I would expect them to want to know things like:
- what the business actually does;
- which customers you most want to reach;
- what those customers usually need to understand before they contact you;
- what questions people ask repeatedly;
- what makes the business different;
- what work matters most;
- what action you want someone to take after visiting the site;
- what is currently working;
- and what is not.
The exact questions will vary.
The important part is whether the provider is trying to understand the job the website needs to do before deciding what it should look like.
If someone can confidently prescribe the entire solution before they understand the business, I would want to know what they are basing that confidence on.
What problem are we solving?
Sometimes this is a question for the designer.
Sometimes it is a question for yourself.
Why are you replacing the website?
Because it looks old? Because nobody can find the information they need? Because the business has changed? Because it is slow? Because you cannot update it? Because customers do not understand what you offer? Because people find you online and the site makes the company look smaller, less established, or less capable than it really is? Because you need functionality the current site cannot support?
Those are very different problems.
They may require different solutions.
A good provider should be willing to help clarify the problem rather than treating “I need a new website” as the diagnosis.
Sometimes the right recommendation is a rebuild.
Sometimes the existing site needs a focused repair.
Sometimes the website is not the primary problem at all.
That distinction matters before the design begins.
What exactly is included in the price?
This sounds obvious.
Ask anyway.
Website proposals can use broad phrases like “SEO included,” “mobile optimized,” “custom design,” “hosting included,” “website support,” and “content assistance.”
Those phrases can describe very different amounts of work.
Ask what they mean.
How many pages? How many revision rounds? Who supplies the writing? Who supplies photography? Does the provider handle the domain? Is hosting part of the project? Are forms included? What about analytics? Search setup? Accessibility checks? Performance testing? Post-launch changes? What happens if the project grows after the original scope is agreed upon?
You do not need every project to contain everything.
You need to know what this project contains.
Clarity at the beginning prevents disappointment at the end.
What will you decide specifically for my business?
This question pairs closely with the idea of a custom website.
If someone says the website will be custom, ask where that customization actually happens.
Will the page structure be designed specifically for the business? Will the homepage hierarchy change based on what customers need to understand? Will the navigation be chosen around the content? Will the visual system be developed specifically for the company? Are you starting from an existing template? Are there reusable components? Is the website being built inside a platform with predefined constraints?
None of those answers is automatically wrong.
You are not trying to catch someone using reusable tools.
You are trying to understand where the important decisions come from.
A provider should be able to explain that without becoming defensive or burying you in technical language.
What do you need from me?
This question tells you a surprising amount about what the project will actually feel like.
Some providers expect the client to deliver finalized page copy, professional photography, service descriptions, team bios, testimonials, branding files, legal language, account access, and a fully formed idea of what each page should contain.
Others take responsibility for much more of the organization and decision-making.
Neither model is inherently better.
But they create very different workloads for the client.
If you are hiring someone because you do not have the time, skill, or desire to figure out the website yourself, discovering halfway through that you were expected to architect the entire thing can be frustrating.
Ask early.
What will they need? When will they need it? What happens if you do not already have it? Who is responsible for moving the project forward?
That is part of the service you are buying too.
What do I control when the project is finished?
I prefer this question to simply asking “Do I own the website?”
Ownership can mean different things depending on how a website is built.
Instead, get specific.
Who controls the domain? Whose account is it registered under? Who controls the hosting? Can you access the website files? Can another developer work on the site later? Are there platform subscriptions? Are any themes, plugins, fonts, images, or software licensed rather than transferred? What happens if you stop working with this provider? If you use a managed website platform, what happens if you leave that platform?
The answers will depend on the build.
But they should be understandable.
The domain deserves particular attention.
ICANN describes the registrant as the individual or entity that registers the domain and manages it through the registrar. Your business should know who the registrant is and how to access the registrar account.
A domain seems like a tiny administrative detail until nobody can log into it.
Then it becomes a very large one.
What will continue costing money after launch?
A website rarely becomes completely cost-free after it launches.
There may be domain renewal, hosting, platform subscriptions, premium plugins, ecommerce fees, scheduling software, form services, maintenance, analytics products, email services, or ongoing support.
Again, recurring costs are not inherently bad.
Some are completely reasonable.
But they should be visible before you commit.
Ask:
What am I paying once, and what am I paying repeatedly?
Then ask:
Which of those recurring costs are required for the website to continue working?
That will tell you much more than the project price alone.
How do you test the finished website?
I care about this question because websites can look finished long before they are finished.
A designer may have checked every page visually and still missed poor mobile behavior, oversized images, broken links, missing form labels, unreadable contrast, search-indexing problems, security configuration issues, slow-loading resources, keyboard-navigation problems, or forms that quietly stopped working.
Ask what happens between “the design looks done” and “the website goes live.”
There are established external standards and tools that can help evaluate different parts of a website.
Google documents Core Web Vitals and other page-experience considerations used to understand how people experience a webpage. W3C publishes the Web Content Accessibility Guidelines, the international technical standard used to guide accessible web content.
A provider does not need to promise perfect scores everywhere.
In fact, I would be suspicious of anyone treating one automated score as proof that the entire website is good.
The useful question is:
What do you test, how do you interpret the results, and what do you do when something fails?
That tells you much more.
How will the site be prepared for search?
I would be careful with the phrase “SEO included.”
SEO can mean everything from properly naming a page to months of keyword research, content strategy, link building, technical remediation, local search work, and ongoing optimization.
Those are not the same service.
For a standard website build, I would want the fundamentals handled correctly: crawlable pages, sensible page titles, descriptive metadata, correct heading structure, useful page content, mobile usability, a sitemap, appropriate indexing settings, clean technical structure, and a way to measure what Google is actually doing after launch.
Google makes an important distinction here: strong page experience and technical fundamentals can support search performance, but there is no single page-experience score that guarantees ranking.
So if someone promises that your new website will automatically rank first because they “do SEO,” ask what that actually means.
A good website should be built so search engines can understand it.
That is different from promising where Google will rank it.
How do revisions work?
This sounds administrative.
It is really about expectations.
How many rounds are included? What counts as a revision? When do you review the work? Can you request changes throughout the project, or at specific stages? What happens if you change your mind about something major? What happens if the provider misunderstood something? What happens if new scope appears?
You do not need unlimited revisions.
Unlimited anything tends to create its own problems.
You need a process that gives you enough opportunity to make the website accurate without leaving both parties in an endless cycle of moving things three pixels back and forth.
A clear revision process protects both sides.
What happens if we discover something unexpected?
Projects change.
The business owner remembers an important service halfway through. An integration turns out to be more complicated than expected. A page needs to be added. The original idea does not work as well once everyone sees it. A technical limitation appears.
This does not necessarily mean the project was scoped badly.
Sometimes you learn by building.
What matters is what happens next.
Does the provider quietly absorb everything until they become resentful? Do they surprise you with a bill? Do they refuse to change anything because it was not in the original proposal? Or do they explain the change, its impact, and the options before moving forward?
You are not looking for a provider who guarantees nothing unexpected will ever happen.
You are looking for one who has a sane way to handle it when it does.
What happens after launch?
Some website providers offer ongoing maintenance. Some offer support retainers. Some include a post-launch window. Some train the client to manage the site. Some hand everything over and step away. Some operate the website for the client indefinitely.
Any of those models can work.
Ask which one you are entering.
And ask what happens if you need something six months later.
Are you required to continue working with the original provider? Can you? Do they charge hourly? Do they offer support packages? Can someone else take over?
There is a difference between having continued support available and being dependent on continued support.
I prefer knowing which one you're buying.
What kind of website are you not the right person to build?
I love this question.
Because nobody is the right provider for every project.
Someone who builds fantastic local service-business websites may not be the right person for a large ecommerce operation. A branding-heavy studio may be overkill for a straightforward five-page site. A developer who specializes in complex web applications may not be particularly interested in marketing websites. A template specialist may be an excellent choice when speed and budget matter more than highly specific design. An agency built for enterprise work may have a process that makes no sense for a two-person business.
The answer you want is not a particular limitation.
You want evidence that the provider knows where their limitations are.
Someone who can tell you, “That isn't really the kind of project I do well,” is giving you useful information.
I trust that more than someone who somehow specializes in everything.
Can you explain one decision in your portfolio?
This may be more revealing than asking “Can I see your work?”
You should absolutely see the work.
But then choose something.
Why is this homepage structured this way? Why is that call to action there? Why did this project use photography differently? Why is one site very restrained and another much more expressive? What problem was the client trying to solve? What changed because of that?
The answer does not have to be complicated.
In fact, a simple answer is often better.
You are listening for whether the design reflects reasoning or whether the explanation begins and ends with “We thought it looked good.”
Aesthetics matter.
But businesses usually need the website to do more than decorate the internet.
Pay attention to how they answer you
There is one final thing I would watch that is harder to put into a proposal.
How does the person make you feel when you ask questions?
Do they explain things clearly? Do they make you feel foolish for not knowing technical terms? Do they answer what you actually asked? Can they say “I don't know” when they do not know? Can they explain a tradeoff without pretending there is only one correct answer? Do they listen? Do they push you toward things you do not understand? Do they tell you when something you requested probably will not help? Can they disagree with you without turning the conversation into a power struggle?
You are probably going to make dozens of decisions together.
The quality of those conversations matters.
You are hiring judgment, not just production
A website provider is obviously being hired to make something.
But the visible website is the result of hundreds of smaller decisions: what comes first; what gets left out; how the pages connect; how much explanation is enough; where someone should click; what needs to be tested; which technology makes sense; what should be custom; what can be reused; what is worth spending money on; and what is not.
That is why I would not choose someone based only on whether their portfolio is attractive.
And I would not choose them because they gave the longest list of included services.
Ask questions that reveal the thinking behind the work.
You do not need them to make every decision the way you would.
You need to understand why you trust them to make decisions you hired them to know how to make.
That is a much better predictor of the working relationship than whether the proposal says “premium,” “strategic,” or “custom” often enough.
And a good web designer should be comfortable helping you understand all of it—even if understanding it ultimately leads you to hire someone else.