How do I know if a web developer is any good before I hire them?

Look for verified work, not just a portfolio

Anyone can curate a gallery of screenshots. What's harder to fake is real, named client work you can actually search for and see live. That's a stronger signal of quality than any polished portfolio page.

Take the time to actually search for the businesses named. A real, live site you can visit and interact with tells you far more than a static screenshot ever could — you can see if it still works, still loads fast, and still looks maintained.

Notice how they talk about security

Security is the area where shortcuts are easiest to take and hide — and most expensive to discover later. How specifically someone talks about hardening, backups, and monitoring tells you a lot about how seriously they take the parts of the job that don't show up in a screenshot.

A vague answer here — "we take security seriously" without specifics — is worth noticing. Someone who actually handles it well can usually describe what that looks like in practical terms, not just reassurance.

Watch what they ask first

A good developer asks about your business before recommending a technology. If the conversation jumps straight to a favorite stack before understanding what you actually need, that's worth noticing — the tool should follow the job, not the other way round.

What this means for you

The best signals of quality rarely show up in a portfolio. They show up in the conversation before any work starts — what gets asked, how specifically security gets discussed, and whether the work they point to is real and still standing.

Check their own website before you check anyone else's

A developer's own website is the easiest test available. It's the one project with zero excuses. No client budget cut a corner here. No rushed deadline forced a shortcut. Everything on it was their own choice. If a developer is good, their own site should show it clearly. This is the one place they had full control.

Open it on your phone first. Not your laptop. Most visitors find you on mobile now. Check how fast it loads. Check whether the design feels current or dated. A slow, outdated site from someone selling "modern websites" is telling you something real. Trust that signal over the pitch itself.

This same test works on any site they mention offhand. Not just their own. A live, working example says more than a polished screenshot ever could. Screenshots don't break. Real websites do. A well-maintained one stays working long after launch. That's a harder thing to fake than a portfolio page. Search for the business by name, not just the link they hand you. A site that's easy to find under its own name is usually a site someone's genuinely proud of.

Notice whether they explain things in plain English

Jargon can go two ways. Sometimes it's precision. Sometimes it's a smokescreen. A developer who can explain a caching layer to a non-technical person usually understands it deeply. One who can't, or won't, might be covering a gap. The words alone don't tell you which one you're getting.

Ask a basic question partway through the call. Something like, "what does that actually mean for my site?" Watch how they respond. If a developer is good at the technical side, they can translate it simply. They won't talk down to you either. Someone who leans harder on jargon when pressed is usually stalling. That's worth noticing in the moment.

Plain language isn't a lack of expertise. It's often the opposite. The people who understand something best are usually the ones who can make it simple. Complexity for its own sake is rarely a good sign. It's especially telling in a conversation you're paying for.

Pay attention to how they talk about pricing

Pricing conversations reveal more than the number itself. A transparent breakdown signals someone running an organized business. That means covering what's included. And what isn't. A vague total with no explanation usually signals the opposite. The number matters less than how it gets explained.

You don't need an exact figure published on a website. You need clarity once you actually ask. If a developer is good at their job, they can explain what you're paying for. In specific terms, not general ones. A shrug, or a flat number with no context, is worth pushing on further.

Ask what triggers an extra cost too. A clear answer here means they've thought through their own process already. Things like extra pages or added functionality should have a defined answer. An answer that dodges the question means the process probably doesn't exist yet. You'd be the one finding that out later, mid-project. Pricing clarity is one of the quietest ways to tell if a developer is good. Notice it before you sign anything.

Ask what happens when something breaks

Every website breaks eventually. A plugin conflict. A failed update. A hosting issue outside anyone's control. The real test isn't whether it happens. It's what the developer says when you ask about it directly. Ask before any of it has actually happened to you.

Ask them plainly: what happens if the site goes down? A confident, specific answer is a good sign here. Something about backups matters too. So does response time. So does knowing exactly who you'd contact. A vague "don't worry, it won't happen" isn't confidence. It's an answer that avoids the actual question being asked.

This single question tends to separate people quickly. Someone who's handled real emergencies before has a process. They can describe it without pausing to think. Someone who hasn't tends to talk around it instead. There's genuinely nothing concrete to describe yet. That gap is easy to hear once you're listening for it. It's a fast way to sense if a developer is good under real pressure. Not just in a calm sales call, where nothing has gone wrong yet.

Read reviews for specifics, not stars

Star ratings are close to meaningless on their own. Anyone can collect five-star reviews that say almost nothing. "Great to work with!" tells you very little. What you actually want are specifics. A client describing a real problem that got solved is worth far more.

Look for details about communication. Look for details about timelines too. Look at how issues were handled mid-project, if any came up. A review that mentions a specific fix is worth ten generic ones stacked together. If a developer is good, past clients tend to describe why they were happy. Not just that they were.

Pay attention to how a developer responds to a negative review, if one exists at all. A calm, specific reply says more than a perfect record ever could. Nobody works with dozens of clients and pleases every single one of them. How disagreements get handled tells you what to expect if yours becomes one too.

What a genuinely good first call actually sounds like

A strong first call feels more like a conversation than a pitch. You should leave it having answered more questions about your business. More than you asked about their process, in fact. That's not an accident. It's usually how the call was structured on purpose.

You should also leave with a rough sense of what happens next. Not just a good feeling about the person you spoke with. If a developer is good at running their business, the call ends with real clarity. What happens next. Roughly when it happens too. A call that ends vague tends to stay vague for the rest of the project.

Notice whether they ask about your actual goals. Not just your budget and your timeline. A site meant to generate leads needs different decisions than one meant to just look credible. Someone asking which one you need is paying attention to the right thing early on.

Warning signs that show up in the sales conversation itself

Some warning signs appear before any work has even started. Pressure to decide immediately is one of the clearest. A "this price is only good today" line is a sales tactic. It's not a technical judgment. Good work rarely needs urgency to sell itself. Noticing this early is often the fastest way to tell if a developer is good. Long before the actual project begins.

Another sign is dismissing your current site without specifics. Or dismissing your current developer the same way. "That old site is terrible" without saying why isn't feedback. It's a sales tactic dressed up as expertise. If a developer is good, criticism comes with reasons attached. Not just a judgment handed down with nothing behind it.

Watch for someone who redirects instead of answering a direct question. Redirecting once might just be normal conversation. Doing it repeatedly, on questions that actually matter to you, is different. That's a pattern worth noticing early. Before you've signed anything or paid a deposit.

Look at how they handle scope and change requests

Ask what happens if you want to change something mid-project. Almost every project shifts a little once it's underway. That's normal. It's expected too. What matters is whether there's a clear, existing process for handling it when it comes up.

A developer with a defined process for scope changes has done this many times. One who seems annoyed by the question probably hasn't thought it through. Neither has one with no real answer at all. If a developer is good, changes get handled without drama. There's no confusion about what it'll actually cost you either.

This matters more than it seems at the start. Almost nobody knows exactly what they want on day one. Plans shift once the real site starts taking shape. A process built to handle that reality is worth more than a rigid plan. Especially one that assumed you'd know everything upfront.

Check for consistency across everything they show you

Compare what they say on the call to what their website actually says. Compare their portfolio claims to what you can independently verify yourself. Small inconsistencies matter more than they might seem to at first. They're often the first crack worth noticing.

A specific claim should hold up when you ask a follow-up question. Something like a type of problem they've solved repeatedly. Vague claims that get vaguer under a bit of pressure are a pattern. Consistency is one of the clearest ways to tell if a developer is good. Confidence alone doesn't tell you nearly as much.

This applies to security claims especially. It's an area where vague reassurance is common. Specifics are much rarer to actually hear. Someone who's genuinely handled hardening, backups, and monitoring across many sites can describe it in concrete terms. Not just a general sense that they've "done security work before" at some point.

How they communicate once the actual project starts

Sales conversations are polished by design. That's normal and expected. What happens after the contract gets signed matters more. Ask directly how updates get handled during the build. A regular check-in, a shared task list, a weekly summary — any specific process counts here. A vague "I'll keep you posted" usually means updates depend on you asking first.

This is one of the harder things to judge before work starts. You're relying on what they describe, not what you've actually seen yet. Still, the description itself is a real signal. Someone who's run this process many times can describe it in detail. Someone who hasn't tends to speak in generalities instead. That gap is exactly how you can tell if a developer is good at managing a project. Not just building one.

Response time deserves a direct question too. Ask how quickly you can expect a reply during business hours. A specific number, even a rough estimate, beats an open-ended answer like "pretty quick." Set that expectation before the project starts. Not partway through, once a slow reply has already become a pattern you're stuck with.

Trust the pattern more than any single answer

No single question decides everything on its own. A great answer to one question doesn't erase a bad answer to another. What matters is the overall pattern across the whole conversation. Look at consistency. Look at clarity. Look at how specific the answers get as the call goes on.

A developer might stumble on one question and still be a strong choice overall. Nobody handles every single question perfectly, and that's fine on its own. What matters more is the general direction of the conversation. Do the answers get more specific the deeper you go? Or do they get vaguer and harder to pin down the longer you push? Write a few notes down right after the call. Memory softens details fast. A quick note keeps the comparison honest. Especially if you're weighing a few developers against each other.

That pattern, more than any one moment, is genuinely how you tell if a developer is good. That's true before you've hired anyone at all. Trust what you noticed across the whole call. Not just the parts that felt polished at the very start. The polish is usually the easiest part to prepare for in advance. The substance underneath it is much harder to fake for an entire conversation.