How to Vet a Web Developer Before You Hire One (2026 Guide)

Most people hire a web developer the way they hire a contractor: they look at a portfolio, get a gut feeling, and hope for the best. That works until it doesn’t, and when it doesn’t you’re stuck with a site you can’t update, code nobody else wants to touch, and a monthly bill for something you don’t understand. Here’s how I’d evaluate a developer if I were the one writing the check.

Start with the questions that have real answers

Anyone can talk about “clean code” and “best practices.” Ask things that force a specific answer.

• Where does the site live, and who owns the account? If the answer is “we handle hosting,” that’s a warning. You should own your domain registrar, your hosting, your DNS, and your code repository. A developer who insists on holding the keys is holding you hostage.
• What happens if I want to leave? The right answer is “you get the repo, the database, and a handoff call.” The wrong answer is silence, or a fee you didn’t know about.
• How do I edit content? If the answer involves calling them for every text change, the site is built for them, not for you.
• Who wrote this code, and can you walk me through it? If they can’t explain a section of their own project, they probably copied it.

Look at the work, but look at it properly

Portfolios lie by omission. A screenshot tells you nothing about whether the site loads in under two seconds on a phone in a parking lot. So open the actual sites.

Run them through real tests

PageSpeed Insights, WebPageTest, and a plain old Chrome DevTools audit will tell you more in five minutes than an hour of conversation. Check the mobile view specifically. Most traffic is mobile, and most portfolios are desktop screenshots.

Then check the boring stuff:

• Does the contact form actually send? Fill it out and see if you get a reply.
• Does the site break when you resize the window?
• Are images served as WebP or AVIF, or are they 4MB JPEGs from 2019?
• Does the page shift around while it loads? That’s layout shift, and it’s a real usability problem.

Ask to see code, not just pixels

If someone is building you a custom site, ask for a small sample of their code. Not a whole project. One component is enough. You’re looking for readable structure, sensible naming, and comments that explain why rather than what.

A healthy React component in 2026 usually looks something like this:

export function ContactForm({ onSubmit }) {
 const [status, setStatus] = useState('idle');

 async function handleSubmit(e) {
 e.preventDefault();
 setStatus('sending');
 const data = Object.fromEntries(new FormData(e.currentTarget));
 const res = await fetch('/api/contact', {
 method: 'POST',
 headers: { 'Content-Type': 'application/json' },
 body: JSON.stringify(data),
 });
 setStatus(res.ok ? 'sent' : 'error');
 }

 return (
 <form onSubmit={handleSubmit}>
 <input name="email" type="email" required />
 <button disabled={status === 'sending'}>
 {status === 'sending' ? 'Sending...' : 'Send'}
 </button>
 {status === 'error' && <p role="alert">Something went wrong.</p>}
 </form>
 );
}

That snippet handles loading state, error state, and accessibility. If the sample you’re shown doesn’t handle failure at all, ask why. Real networks fail.

Red flags that should end the conversation

• No contract, or a contract with no scope. Vague scope means every change is a fight.
• They own your domain. This is the single most common way people get stuck. Register it yourself today.
• No staging environment. Editing a live site with no preview is how businesses go down on a Tuesday afternoon.
• They can’t name a single accessibility standard. WCAG 2.2 is the current baseline. If they’ve never heard of it, they’re building for a subset of your customers.
• Every answer is “yes.” A good developer tells you when your idea is expensive, unnecessary, or a bad fit. Pushback is a feature.

What good looks like

A solid developer will ask you questions first. What’s the site for? Who’s visiting? What happens after someone fills out the form? They’ll talk about performance budgets and hosting costs before they talk about fonts. They’ll give you a written scope, a timeline with a range, and a clear answer on ownership.

If you’re weighing a full rebuild versus patching what you have, that’s usually a scope conversation, not a technology one. I do custom web development for small businesses around Commack and the rest of Long Island, and most of the first call is figuring out which of those two you actually need.

Don’t skip the trial run

Before committing to a full project, pay for one small thing. A landing page. A bug fix. A performance audit. You’ll learn more about how someone works from a two-day job than from three reference calls. If the small job goes well, the big one probably will too. If it doesn’t, you spent a few hundred dollars instead of a few thousand.

FAQ

How much should a small business website cost in 2026?

For a custom site with a handful of pages, a CMS, and proper performance work, you’re generally looking at a few thousand dollars up front plus modest hosting costs. Anything dramatically cheaper usually means a template with your logo dropped in, and anything dramatically higher should come with a written explanation of what you’re getting.

Should I use WordPress, a site builder, or custom code?

It depends on who’s maintaining it. If you want to edit content yourself without touching code, WordPress or a modern headless CMS is a reasonable fit. If the site is mostly a marketing presence, a good static site is faster and cheaper to host. Custom code makes sense when you have actual application logic, not just pages.

Can I switch developers later without rebuilding everything?

Yes, if you set it up right from the start. Own your domain, hosting, and repository. Insist on documented setup steps. Any competent developer can pick up a well-organized project. The ones that can’t be handed off are the ones you want to avoid in the first place.