How to Hire a Website Developer: A Practical Process
Choosing a website developer is mostly a matter of evidence gathering, and most people gather the wrong evidence: portfolios, which show the best work rather than the typical work, and price, which compares things that are not comparable.
This guide covers a process that produces better outcomes — what to send out, what to ask, what to check, and when to stop.
Send the same brief to everyone#
Quotes are only comparable if they answer the same question. A one-page brief plus a page structure is enough, and it removes most of the variance that makes quotes look wildly different.
- What the site must achieve, and the one action that matters most.
- A page list, marked launch-critical or later.
- The functional requirements: forms, search, accounts, checkout, integrations.
- What is out of scope — content writing, photography, ongoing SEO.
- Your budget range. Withholding it wastes everyone’s time and produces quotes you cannot use.
- Your deadline and what is driving it.
- How you will decide, and by when.
Giving a budget range does not mean you will be charged the top of it. It means the proposals you receive will be for projects you can actually buy.
What to ask, and what the answers mean#
These questions separate developers who have finished projects from those who have started them.
| Question | What a good answer sounds like |
|---|---|
| Show me a site like mine at my scale | A live URL, not a portfolio image, with context |
| Who owns the code and the accounts? | "You do" — immediately, without qualification |
| How does a change reach production? | Version control and a deployment process, not FTP |
| What happens if something breaks after launch? | A defined support window and what follows it |
| What is not included? | A specific list, offered without being pushed |
| What could make this project go wrong? | Honest risks — content delays, integrations, decisions |
| Who will actually do the work? | Named people, not "our team" |
| What do you need from us? | A clear list with dates |
Check the evidence yourself#
Twenty minutes of independent checking is worth more than an hour of conversation, because it tests the work rather than the pitch.
- Open two of their live sites on a phone, on mobile data.
- Run one through a performance test and look at the result honestly.
- Tab through a page with the keyboard and see whether focus is visible.
- View source: is there a title, a meta description, sane heading structure?
- Speak to one previous client — and ask specifically about a time something went wrong.
- Check whether their own site is maintained. It is not decisive, but it is a signal.
The most useful reference question is not "were you happy" but "what happened when something went wrong, and how did they handle it?" Every project has one of those.
Red flags and green flags#
Patterns worth weighting heavily in either direction.
| Red flag | Green flag |
|---|---|
| A quote within an hour, without questions | Questions about your business before quoting |
| Guaranteed first-page rankings | Explaining that nobody can guarantee rankings |
| Vague scope with a fixed price | An explicit out-of-scope list |
| They hold the domain or hosting | Everything registered in your name |
| No staging environment | You review on staging from the first template |
| Unwilling to give references | Offers them before you ask |
| Pressure to sign this week | Willing to wait while you compare |
| Full payment up front | Milestone payments tied to deliverables |
Frequently asked questions
Should I choose the cheapest quote?
Only if it is answering the same question as the others. A quote far below the rest usually excludes something — content entry, testing, post-launch fixes — or has not read the brief. Ask what is excluded, in writing, then compare total year-one cost including maintenance and what you own at the end.
How do I judge a developer if I am not technical?
Judge process and evidence rather than technology. Can they show you a live site at your scale? Do they use version control and staging? Will they answer "who owns the code?" without hesitating? Do they ask about your business? None of that requires technical knowledge, and it predicts outcomes better than the stack does.
What should be in the contract?
Scope with an explicit exclusions list, milestones and payments, ownership of code, domain and accounts, revision rounds, what happens after launch, response times for problems, and notice periods. If there is one clause to insist on, it is ownership — everything else can be renegotiated later, that one cannot.
How many developers should I approach?
Three to five is the useful range. Fewer and you have nothing to compare; more and the effort of evaluating exceeds the value of the extra options, and you will keep everyone waiting. Send the same brief to all of them and set a decision date so the process ends.
hire a website developerhow to choose a web developerwebsite developer questionsweb development contracthiring developerswebsite quotes
