Hire a web developer: what to look for

“Hire a web developer” is a search with two kinds of searchers. One is hiring for a job opening — if that is you, this is the wrong article. The other wants someone to build a website or solve a technical problem, and faces a more practical question: how do you judge someone who makes something you cannot judge yourself?

That is the question I answer here. I am a freelance web developer myself — usually the person people with this question find first. This is the evaluation framework I hand them, even when they end up hiring someone else.

You judge a web developer on four things: work you can see, code someone else can take over, references you can call, and an arrangement for after the launch. Everything below hangs on those four.

Where to find a good web developer

Before you can evaluate, you need candidates. Three channels, each with its own proof:

• Your network and suppliers. A print shop, bookkeeper or copywriter who works alongside developers knows the names that deliver. A recommendation mostly proves collaboration: someone kept their promises.
• Open source and personal work. Developers who contribute to public projects or keep a careful portfolio of their own show craft and care — you see the work itself.
• Platforms with a review history. Reviews prove repeated satisfaction across different clients. Read the replies to critical reviews; that is where you learn how someone communicates under pressure.

No single channel is enough. Combine two: network plus portfolio, or platform plus a reference call.

The portfolio says more than the price

A portfolio is not a price list. This is what I check when I review a colleague’s work:

• Are the sites still live? Mockups are presentations; live sites are reality. Open two or three, click around, use the contact form.
• Do they do their job? A site does not need to win awards; it needs to move visitors toward an action. Within ten seconds you should understand what the company does and what you can do there.
• How fast do they load on your phone? Poor speed is a technical shortfall, not a matter of taste. A developer who leaves that lying around leaves more lying around.
• Is there variety in project types? Five nearly identical sites prove one template. A frontend build for a rental company looks different from an online store or a members’ site.

For each portfolio piece, ask about the developer’s role. Who built exactly what, and what came from a team or the client? An honest answer (“their own designer made that layout; I did the build and the integrations”) weighs more than vague claiming.

Checking code quality without being a developer

The question I get most: “but how do I know whether the code is any good?” You do not need to read code to get close. Ask these three questions:

• Do you work with version control? Every professional developer uses Git or an equivalent. “Version control” sounds technical, but it means: every change can be reverted and accounted for. A no here is a red flag.
• May a colleague review the code? A developer confident in their work has no problem with that. Ask whether another developer may inspect or take over the work — for a second opinion, or in case you part ways later.
• Can someone else take this over later? Ask it exactly like that. The answer reveals whether you get a widely used CMS or framework, or a custom construction only the builder understands. That last one is called lock-in, and it is one of the three pitfalls below.

You only notice the difference after the launch. So ask for a site that is about a year old and check how it performs now and who maintains it.

References: what to actually ask

Almost everyone asks for references; almost nobody asks the right questions. “Were you satisfied?” always gets a yes. These three questions uncover something:

• How did communication go when something slipped? Every project has friction. You want to know how it went when it got tense, not whether it was perfect.
• What happened after the launch? Did you get an answer within days, or did the developer disappear behind a support form? Post-launch support is a chapter of its own, below.
• Would you hire this developer again for a bigger project? That question forces a weighing of price, comfort and trust, and produces more honest answers than a satisfaction score.

One ten-minute reference call says more than ten pages of reviews.

What good communication reveals

You cannot read collaboration quality from code, but you can from communication. Three signals I would check:

• Fixed moments. A short weekly update or a fixed check-in works better than “I’ll hear when it’s done”. Ask how the developer reports progress.
• Questions coming back. When you hire a web developer for your project, questions should come back about your goals, your customers and your content. Someone who only confirms what you say builds your assumptions, not your site.
• A plan with milestones. One final deadline is a gamble; a sequence of milestones — design, first version, testing, launch — is a plan. You can adjust at every station before everything is finished.

Communication is not a soft skill here. In a technical track of weeks or months, it is the only way you as a client keep grip on the process.

Support after the launch

Websites are not a one-time delivery. Plugins, frameworks and hosting keep moving, and so does your own content. Discuss what happens after the launch before the project starts. I call that website maintenance, and it covers at least:

• Who owns what? Code, domain, hosting account: ask explicitly whose name is on them and make sure that is you. You want to be able to switch developers without asking permission.
• What does the arrangement cover? Updates, backups, security, small changes: write down what is included and what continues at an agreed rate.
• How is it measured? Agreements about conversion or speed are only honest when they are measured too. Ask for a baseline before the build and periodic measurements after it, so you know the site does what it promised.

A developer who avoids this conversation disappears after the launch. One who raises it themselves is already thinking about your site a year from now.

Three pitfalls when hiring

In more than 25 years of building I have seen these three pass by most often — usually with clients who just missed them:

• The cheapest option. The lowest price is rarely the lowest cost. A site that has to be rebuilt after a year costs more than one that was right the first time. Compare quotes on scope, not on amount.
• No maintenance arrangement. “Let’s figure that out later” in practice means never. A site without an update agreement quietly decays, and the repair afterwards is bigger than the maintenance before.
• Vendor lock-in. Custom work only the builder understands looks like tailored care but is a relationship without an exit. Ask whether another developer can take over the work, and take “no, that’s our system” seriously as an answer.

All three pitfalls share one remedy: write down scope, ownership and maintenance before the start. One page is enough.

Not sure whether you need a web designer or a web developer?

Many people searching to hire a web developer were really after something else. If your main doubt is who you need — the visual side or the technical side — the question is not “who is better” but “what exactly needs to happen”. For mostly visual work, compare the approach of a freelance web developer for hire with that of a freelance web designer; the profiles complement each other and overlap less than the terms suggest.

Doubting mostly about budget? The frameworks and price drivers of a website are covered in website development costs — what holds for judging a developer above holds for judging a quote there.

And if you prefer a single point of contact running from intake to UX and maintenance, read how we approach getting a website built — though you are welcome to ask us the questions from this guide either way.