- hiring
- web development
- buyers guide
5 Questions to Ask Before You Hire a Web Developer
None of these are technical. You don't need to understand code to ask them — and the answers tell you more than any portfolio.
Md Ariful Islam
4 min read
Hiring a developer is uncomfortable because you're buying something you can't evaluate. You look at their portfolio. Every site looks fine. You pick based on gut feeling and price, and hope.
The portfolio doesn't help much, by the way. It shows you the visual result, not whether the project ran on time, whether the client could update it afterwards, or whether it still works two years later.
These five questions get closer. I've been asked all of them, and the ones that made me think hardest predicted the best projects.
None of them require you to understand code.
1. "What will you measure before you start?"
Why it works: if there's no baseline, nobody can prove the work helped.
You'll spend real money. Three months later, is the site better? "It looks nicer" is an opinion. "Load time went from 3.5 seconds to 0.9, and mobile enquiries are up 30%" is a fact.
You can only have the fact if someone wrote down the starting point.
Good answer: they name specific things — current load time, current conversion rate, how you rank now, where people currently drop off. They want access to your analytics.
Bad answer: "We'll make it much faster and more modern." That's a promise with nothing behind it.
2. "What happens to this after you leave?"
Why it works: web projects rarely fail at launch. They fail in month eighteen.
The person who built it has moved on. You need a small change. The new developer looks at the code, can't follow it, and quotes you for a rebuild. You pay twice for the same website.
Good answer: they talk about documentation, about writing code the next person can follow, about handing over accounts and access. Ask to see documentation they wrote for a project they no longer support — that's the real test, because nobody was watching.
Bad answer: "Don't worry, I'll always be around." Nobody is always around.
3. "What would you tell me not to do?"
Why it works: it separates the people selling from the people thinking.
Someone who agrees with every idea you have is agreeing because agreement closes deals. Someone who says "I wouldn't do that, here's why" is applying judgment — and judgment is the thing you're actually paying for.
Good answer: a specific thing, with a reason. "I'd skip the animated intro. It's the heaviest thing on the page and most people scroll past it."
Bad answer: "Everything you've described sounds great!"
I've talked people out of full redesigns when the real problem was three days of performance work. Worse quarter for me. Better year for them.
4. "Who else has worked on this codebase?"
Why it works: it reveals whether they build for themselves or for other people.
Code that only its author understands is a liability disguised as an asset. It works today, and it traps you tomorrow.
Good answer: they explain how they write so someone else can pick it up. Naming that makes sense. Structure that's predictable. Comments where something is genuinely odd.
Bad answer: "Just me, so it's exactly how I like it." That's not reassurance.
I maintain an open-source component library used by teams I've never spoken to. That taught me more about this than any client project could — when a stranger downloads your code at 2am, you're not there to explain it. Every assumption you left undocumented becomes a complaint.
5. "What's the smallest version of this that would still be worth doing?"
Why it works: every good developer has an answer ready.
It tells you whether they're solving your problem or building their portfolio.
It also gives you an exit. Start with the small version, see how they work, expand if it goes well. Far safer than committing your full budget to someone you've never worked with.
Good answer: a real reduced scope. "Rebuild the three pages that get 80% of your traffic first. See what happens to the numbers. Then decide on the rest."
Bad answer: "It all needs doing together." Sometimes true. Usually not.
Two quiet warning signs
A quote with no breakdown. If you can't see what you're paying for, you can't tell whether it's fair, and you can't tell later what was skipped.
No questions about your business. Someone who asks only about pages and features, and never about customers or what the site is supposed to achieve, will build exactly what you asked for — which is often not what you needed.
One thing that isn't a warning sign
Being in another country. Rates vary enormously by location, and cheaper doesn't mean worse.
Judge by the answers above, by whether they communicate clearly in writing, and by whether they ask good questions back. Those predict outcomes. Geography doesn't.
Worth saving before your next hire. And if you want a second opinion on a quote you've received, send it over — I'll tell you what I'd ask about it.
