Questions to Ask a Web Developer Before Hiring Them

The questions to ask a web developer before hiring are not about technology. They are about ownership, staffing, change and exit — the four things that decide whether you can walk away later without losing the work you paid for. Whether the team uses one framework or another matters far less than whether your name is on the domain.

I answer these questions for a living. Ten years of sitting on the supplier's side of that table has taught me which ones make an agency uncomfortable, and being asked them properly is a relief rather than an insult. A client who asks them is a client who will read the contract, which means fewer arguments later.

Here they are, in the order I would ask them, with the answers that should end the conversation.

The short version

1. Who owns the code when we are finished?

Ask it plainly, and ask for the answer in the contract rather than in an email.

The default in many agreements is that the developer retains ownership and grants you a licence to use the site. That is a legitimate commercial model — it is how most product companies work — but you should know you are buying it, because a licence is not a transfer, and a licence can have conditions.

What you want is full assignment of the intellectual property on final payment: the application code, the design source files, and any custom plugin, theme or module written for you. Open-source dependencies stay under their own licences, which is normal and fine.

Answers that should worry you. "You own the design, we own the code." "The code is proprietary to our platform." "You own it as long as you host with us." That last one is not ownership; it is a tenancy. It shows up most often with agencies running a shared in-house framework, and the cost only becomes visible when you want to move.

Ask a second question to test the first: if we hired someone else next year, could they take this and continue? Watch what happens to the pause before the answer.

2. Whose name is on the domain, the hosting and the analytics?

This is the question that decides whether you can leave today or in six weeks, and it is the one buyers most often forget.

Every account should be registered to your organisation's email, with the agency added as a user. Domain registrar, DNS, hosting, analytics, search console, email, CDN, any paid plugin licence. Agencies frequently set these up under their own accounts because it is faster, and most will move them without fuss when asked. The problem is the ones that will not.

Registrars also apply their own locks and waiting periods around transfers and registrant changes, so the time to fix this is at the start, not during a dispute. Check the policy of the registrar being used rather than assuming.

Answers that should worry you. "We manage all that for you, do not worry about it." "It is on our reseller account." "We can move it after the project completes." There is no technical reason an account cannot be in your name from day one, so any resistance is commercial.

3. Who is actually doing the work?

Agencies sell with their best people. Not all of them deliver with them.

Ask for the names of the individuals on your project, whether they are employed or subcontracted, roughly what each will spend on it, and what happens if one leaves mid-project. Then ask to speak to the person who will write the code, for fifteen minutes, before you sign.

This is not about junior developers being bad. Juniors doing supervised work at a sensible rate is how a healthy team operates and how good developers are made. It is about the gap between what you were sold and what you receive, and about whether anyone senior is reviewing the output.

Answers that should worry you. "You will have a dedicated account manager" in response to a question about developers. "We allocate resources based on availability." An unwillingness to name anybody. If the proposal names a senior lead, ask what share of the work is theirs and get the answer into the contract.

Subcontracting is not disqualifying, but undisclosed subcontracting is. Ask directly.

4. How do we handle a change once we have started?

Every project changes. The question is what the process costs.

You are looking for a threshold: something below which a change is simply absorbed as part of the work, and above which it gets scoped and priced. Without that threshold, a fixed price project accumulates small known problems nobody fixes because the paperwork exceeds the change.

Ask how changes are estimated, who approves them, how long the process takes, and whether small ones need one at all. Ask what has happened on their last few projects — an agency that says changes rarely come up is either very lucky or not listening.

This is really a question about the contract model underneath the quote, and it is worth understanding that before you choose one. We wrote the whole argument up in fixed price vs time and materials: a fixed price makes every change a negotiation, and time and materials makes every change a bill.

Answers that should worry you. "We are flexible, we will look after you." That is generosity, not a process, and generosity runs out when a project runs late. Also worrying: a change process with no threshold, and a change process where the estimate for the change is not itemised.

5. What happens if we part ways halfway through?

Ask this cheerfully at the start, because it is unanswerable politely once things have gone wrong.

What you want to hear: you receive the code as it stands, you keep access to every account, you are invoiced for work completed, and there is a defined notice period. Nothing is withheld as leverage.

Answers that should worry you. "We would hand over on final settlement of all invoices" — reasonable-sounding, and functionally a hostage clause when the dispute is about an invoice. "The domain transfers when the project completes." "We do not release the repository until launch." A supplier confident in their work does not need to hold your assets to guarantee payment; that is what a milestone schedule is for.

The mirror image applies to you. Expect to pay for work actually done. Agencies have their own version of this story, and the reason exit clauses get written badly is usually that both sides have been burned.

6. What exactly is in the handover?

Ask for the handover contents as a list, in the proposal, before you sign. It is the single best predictor of what the codebase is like, because an agency that writes documentation writes it for themselves first.

A handover that works contains, at minimum:

• Repository access with the full commit history, not a zip file of the final state
• Credentials for every account, in your name, with any shared access removed
• Deployment instructions and the environment variables a new developer needs
• A list of third-party services, what each does, and what each costs
• Design source files, not only exported images
• A short written note of anything non-obvious: the scheduled jobs, the workaround, the thing that will look wrong but is deliberate
• Whatever training your team needs to actually edit the thing

That last point deserves attention on content-managed sites. A WordPress build is only as good as your team's ability to use it, and a handover with no training produces a site nobody dares touch, which then rots.

Answers that should worry you. "We will walk you through it on a call." A call is not a handover; it is a handover being delivered verbally to someone who will forget it. Also: a zip file instead of a repository, which tells you there is no meaningful version history to give you.

7. What does the first invoice cover, and what triggers the next?

Deposits are normal. Agencies carry real risk at the start of a project, and asking for money before beginning is not a red flag.

What matters is whether the deposit buys something defined. Tie payments to delivered milestones rather than to calendar dates, and make sure the first milestone produces an artefact you keep whatever happens next — a scope document, a design, a working environment.

This is the strongest practical argument for paying for a discovery phase as a separate, small engagement. You get a real deliverable, you find out how the team works, and you learn whether their estimate was reasonable before committing the rest of the budget.

Answers that should worry you. A large deposit tied to nothing in particular. Payment schedules based purely on dates, which pay for elapsed time rather than progress. And any refusal to say what you keep if the project stops after the first payment.

8. What happens after launch?

Launch is the middle of a website's life, not the end of it. Ask what the arrangement is afterwards, and get a number.

Specifically: who applies security and dependency updates, what the response time is when something breaks, whether there is a backup and whether anyone has tested restoring it, what hosting actually costs, and whether support is included for a period or billed separately from day one.

Ask how they would handle the site's performance and search health over time as well. Anyone can show you a good PageSpeed Insights score on launch day with no content in the CMS. The interesting question is what happens after your marketing team has added a hero video and four tracking scripts.

While you are there, ask what accessibility standard they build to. WCAG is the reference everyone means, and the honest answer is a specific level with a named testing approach. "We follow best practices" means nobody has tested anything.

Answers that should worry you. "It is covered" without a scope. An unlimited support promise, which is either priced into the build or will quietly stop being honoured. And no mention of updates at all, which is how a site becomes a security problem eighteen months later.

Questions that sound useful but are not

A few standard interview questions produce answers that cannot distinguish one agency from another:

• "How many years have you been doing this?" Longevity is not delivery quality. Ask for work of a similar shape instead.
• "Do you use the latest technology?" You want the appropriate technology and a large hiring pool, not the newest thing. A stack nobody else knows is supplier lock-in by another name, which is one of the arguments in our case against headless WordPress.
• "Can you guarantee first-page rankings?" Nobody can, and an agency that says yes has just told you what their claims are worth. Ask how they measure search performance instead, and what they would report monthly.
• "How long will it take?" Useless without a scope. The answer worth having is what drives the timeline and what would make it slip.

What to ask for alongside the answers

Two practical requests that reveal more than any question.

Ask for a reference you choose, not one they offer. Look at their published work, pick a project that resembles yours, and ask to speak to that client. Then ask that client one question: what was it like when something went wrong?

Ask for a written scope with exclusions. Not a features list — a document that names what is not included. Single language only, no bulk import, no offline mode. The exclusions section is where honest scoping shows, and its absence is the most reliable predictor of an argument in month three.

If you are still deciding whether to hire anybody at all rather than use a site builder, that fork comes before all of this and we covered it in AI website builders versus professional development.

The decision rule

Hire the agency that answers the ownership, staffing and exit questions without hesitating, even if their quote is higher than someone who did not. Price differences between competent suppliers are usually smaller than the cost of being locked into an incompetent one.

Get the answers to questions one, two, five and six into the contract. The rest can live in email. And if a supplier treats the whole list as a lack of trust rather than as due diligence, you have learned what their difficult conversations are going to feel like. The work in our personal brand site case study began with a version of exactly this conversation, and every good web design and development engagement we have run started the same way.