What to look for when hiring a developer
What questions to ask, what answers to look for, and what warning signs to avoid when hiring a freelance or agency web developer.
Hiring a web developer is difficult if you're not technical. You can't easily assess the quality of the work from the outside, and good-sounding answers in a meeting don't necessarily mean good work in practice.
After more than a decade building for clients, I've heard the stories from the other side — businesses that hired the wrong person, got burned, and came to me to pick up the pieces. The same patterns come up repeatedly.
Here's what I'd actually look for.
What to look at before you meet them
Their portfolio — really look at it
Don't just glance at the screenshots. Click through the live sites. Do they work? Do they load quickly? Do they look right on your phone? A portfolio of attractive mockups that lead to broken or slow websites is telling you something.
Check the recency. A portfolio of sites from 2019 could indicate someone who hasn't kept up with how the web has changed, or simply that they've been doing other things. Either way, worth asking about.
What they write or say publicly
Blogs, case studies, GitHub profiles — these are better signals than a polished website. A developer who writes about what they've learned, what went wrong, and why they made certain decisions is showing you how they think. That's more useful than a list of technologies.
A GitHub profile with recent commits tells you they're actively building things. A developer who can't point to anything they've written or built outside of client work isn't necessarily bad — but it makes assessment harder.
Questions worth asking in a first meeting
"What's your preferred tech stack and why?"
There isn't one right answer. But there is a difference between "I use X because it's what I know" and "I use X because it's the right fit for this type of project, though I'd consider Y if your requirements pointed that way."
The first answer is honest but limited. The second suggests someone who makes considered choices, not just habitual ones.
"Walk me through a project that went wrong. What happened and what did you do?"
Every developer has these. Projects that went over time, features that had to be rebuilt, integrations that turned out to be harder than expected. A developer who's never encountered these things either hasn't done much work or isn't being straight with you.
What you're actually assessing: how they handle problems. Do they communicate early? Do they take responsibility? Do they find solutions? The answer to this question is worth more than almost anything else they'll tell you.
"How do you handle change requests during a project?"
This is where miscommunication most commonly lives. Does the developer have a clear process for when requirements change mid-project? Or do they wing it and deal with the awkwardness at invoice time?
Neither extreme is good — a developer who refuses any deviation from the original scope is inflexible; one who absorbs everything without tracking it will either resent you or overcharge you. What you want is someone who can say: "that's outside the original scope, here's what it adds and here are your options."
"Who owns the code and files when we're done?"
You should own everything: the code, the domain, the hosting account, the admin credentials. If a developer can't give you a clear yes, that's a problem. Arrangements where the developer retains ownership of the work (beyond standard copyright law) are unusual and not in your favour.
"What happens after launch?"
Websites need maintenance. Frameworks and dependencies get security updates. APIs change. Content changes. Things break. What's the arrangement for ongoing support? Is it a retainer? An hourly rate? A "goodwill" situation that evaporates when the next big client comes along?
You don't want to find yourself unable to get hold of the person who built your site when something goes wrong six months later.
Warning signs
They can't explain what they do clearly. If a developer can't describe their process and their work in terms a non-developer can follow, that's a communication risk. Technical ability and communication ability are separate skills, and you need both.
They're vague about what's included in the quote. A solid quote specifies what's in scope. If you can't get a clear written breakdown, the ambiguity will cost you.
They discourage you from getting other quotes. Good developers are confident in their work. They don't need exclusivity arrangements or pressure tactics.
They tell you what you want to hear rather than what's true. "Yes, that's easy, no problem" in response to every question is not reassuring — it suggests someone who hasn't fully thought it through, or who'll avoid difficult conversations.
They can't point to a maintained, working, recent example. Portfolios with only older work, or with sites you can't verify are live, are harder to trust.
The honest summary
You're looking for competence, communication, and reliability — in roughly that order, though they're all important.
Competence is the hardest to assess without technical knowledge, which is why the portfolio and the process questions matter. Communication you can assess directly in the meeting. Reliability you mostly assess from their professional history — length of time in business, references if you can get them, how they respond to questions.
A developer who's technically average but communicates clearly and reliably will usually give you a better experience than a technically brilliant one who goes quiet for weeks and delivers surprises at the end.
Looking for a developer for your project? Get in touch — if I'm the right fit, brilliant. If not, I'll tell you what to look for.