Questions to Ask a Web Developer Before You Hire
Most questions asked in a first call are about technology, and technology is the part that matters least to whether the project succeeds. The questions that predict outcomes are about process, ownership and what happens when something goes wrong.
This guide lists those questions, grouped by what they reveal, with a note on what a good answer sounds like.
About the work itself#
These establish whether they have understood your project or are describing their standard offering.
| Question | Listen for |
|---|---|
| What questions do you have about our business? | Any at all. Silence here is the strongest negative signal there is |
| Show me a live site at our scale | A URL, not an image; ideally not their showcase piece |
| What would you do differently from our current site? | Specific observations, meaning they looked |
| What is the riskiest part of this project? | An honest answer — usually content or integrations |
| What is not included in this quote? | A specific list offered readily |
| How long, and what drives that? | A schedule with dependencies, not a single number |
About process#
These separate developers who have a repeatable way of working from those who improvise.
- Where is the code stored, and will we have access from day one?
- How does a change get from your machine to the live site?
- Where do we review work before it goes live?
- How often will we see progress, and in what form?
- Who exactly will do the work, and what happens if they are unavailable?
- How do you test — browsers, devices, accessibility, performance?
- What do you need from us, and by when?
The deployment question is the single most revealing one. An answer involving dragging files into an FTP client tells you there is no version control, no staging and no rollback.
About what happens afterwards#
The period nobody asks about during the pitch and everybody cares about six months later.
- Who owns the code, the domain and the hosting accounts after launch?
- What support is included after launch, for how long, and what counts as a defect?
- What does a small change cost afterwards, and what is the turnaround?
- Do you offer maintenance, what is in it, and do we receive a report?
- If we stop working together, what do we receive and how quickly?
- Can another developer take this over? What documentation exists?
- What third-party services will the site depend on, and who pays for them?
Answers that should end the conversation#
Rare, but worth recognising immediately.
| Answer | Why it disqualifies |
|---|---|
| "We guarantee first-page rankings" | Nobody can; it is either ignorance or dishonesty |
| "We keep the domain in our account" | It makes you a hostage |
| "You do not need staging, we are careful" | Everyone is careful; that is not a process |
| "We do not use version control for small sites" | No history, no rollback, no second developer |
| "The price is only valid if you sign today" | Pressure tactics predict the working relationship |
| "SEO is included" with no detail | Either meaningless or a separate service being implied |
| "We will figure out the details as we go" | On a fixed price, this becomes your problem |
Frequently asked questions
What is the single most useful question?
"How does a change get from your machine to the live site?" It is answerable in one sentence by anyone competent, and the answer reveals whether version control, staging, review and rollback exist. Everything else on the process list tends to follow from it in one direction or the other.
Should I ask about specific technologies?
Only where you have a genuine constraint — an existing system, a platform your team already runs. Otherwise the technology is their decision and asking about it invites an answer designed to impress. Ask what outcomes it produces: how fast, how maintainable, who else could work on it.
How do I check a reference properly?
Ask about a problem rather than about satisfaction: "what went wrong, and how did they handle it?" Every project has something. A reference who cannot name anything either had a trivial project or is not being candid. Also ask whether they would use them again for a bigger project, which is a sharper question than whether they were happy.
Is it rude to ask about ownership and termination?
No, and a professional supplier expects it. Both parties benefit from knowing where they stand, and the answers are short. Discomfort with these questions is itself information — it usually means the standard arrangement is less favourable to you than it should be.
questions to ask a web developerhiring a developerweb developer interviewwebsite project questionschoosing a developerdeveloper evaluation
