How to hire a freelance web developer (without regretting it)

Hiring a developer is uncomfortable because you're buying something you can't inspect before it exists, from someone whose work you can't fully judge, in a field where the vocabulary is designed to make you nod along. Most bad website projects don't fail because the developer couldn't code. They fail because nobody agreed what was being built, and both sides discovered that in week five.

I've been on the receiving end of these conversations for eight years, and I've watched clients arrive carrying the debris of a previous attempt more times than I'd like. This is what I'd tell a friend who asked me how to do it properly.

Decide what you're actually buying

Before you talk to anyone, answer one question: what has to be true six months after launch for this to have been worth the money? Not "a nice website." Fifty qualified enquiries a month. Twenty online orders a week. Staff no longer answering the same question by phone forty times a day. A site your team can update without calling anyone.

This matters because it changes who you should hire. A designer-heavy freelancer is the right call for a brand-led site where the look carries the value. Someone with ecommerce depth is right for a store. Someone strong on technical SEO is right if the whole point is organic traffic. These are genuinely different people, and the best one in the wrong category will still disappoint you.

It also tells you what you don't need. Plenty of businesses ask for a custom build when a well-executed five-page site would do the job, and the money would be better spent on photography and a content budget.

Where to look

Referrals from businesses like yours. Still the highest hit rate by a distance. Ask someone whose site you admire who built it and whether they'd use them again — the second half of that question is the one that matters.

Marketplaces (Upwork, Fiverr, Malt, Workana). Useful for volume and for the protection of escrow payments. The tradeoff is that these platforms reward speed and low prices, so you'll wade through proposals that were written by a bot in four seconds. A proposal that mentions something specific about your business is worth ten that don't.

Platform directories. Shopify Partners, Webflow's Experts directory and similar programmes list people who have actually delivered work on that platform. Narrower pool, higher floor.

LinkedIn and local networks. Slower, but it's where you find developers who work in your language and time zone and can sit in a meeting when it matters.

Get three quotes. Not one, because you'll have no reference point. Not eight, because you'll spend a month comparing and the good ones will have taken other work.

Write a brief that gets comparable quotes

Here's the mechanism most people miss: vague briefs don't produce vague quotes, they produce incomparable ones. If you say "I need a website for my clinic," one developer prices five pages, another prices twelve pages with an online booking system, and a third prices a template with your logo on it. Three numbers, wildly different, and none of them tells you anything about the developers.

A brief that fixes this is short. One page covering:

• What the business does, in two lines, and who buys from you.
• The goal, in measurable terms — the six-month question from above.
• A page list. Even a rough one. "Home, about, four service pages, blog, contact."
• Functionality: forms, bookings, payments, memberships, languages, integrations with tools you already pay for.
• What exists already: current site, hosting, domain, logo, photography, text.
• What you'll provide vs what you need from them. Content is the single most common cause of delay.
• Two or three sites you like, and one line each on why.
• Your deadline, and whether it's real or aspirational.

Send the same document to all three. Now the differences between the quotes tell you something about the people who wrote them instead of about how each one guessed.

How to evaluate a portfolio

Don't judge portfolios on prettiness. Judge them on evidence. Four things to do, none of which takes long:

Open the sites on your phone. Not the screenshots — the live sites. Most of your visitors will arrive on a phone, and a portfolio full of desktop mockups that fall apart at 390 pixels tells you exactly how much attention mobile got.

Check whether they're still live. A portfolio where half the links are dead, parked or redirected means either the clients left or the work is old. Both are worth knowing.

Look for your kind of problem, not your industry. Multi-branch business, large catalog, booking flow, two languages, membership area — those are the hard parts. A developer who has solved yours before is worth more than one who happens to have built for another dentist.

Ask what they specifically did. On agency work and team projects, "I built this" can mean anything. The answer to "what part was yours, and what was hard about it?" separates people fast. Real answers are specific and slightly unflattering; invented ones stay smooth and general.

Nine questions worth asking

1. Who will actually do the work? If it's being passed to a team you'll never meet, you should know now.
2. What's included, itemised? Design, development, content loading, forms, SEO setup, training, hosting setup — get it listed rather than implied.
3. How many revision rounds are included, and what counts as one? "Unlimited revisions" is either a lie or a price built to absorb the pain.
4. Who owns the site when it's paid for? Code, design and content should be yours.
5. Whose accounts hold the hosting and domain? They should be in your name, with your billing. This is the single most common way people get held hostage.
6. Will I be able to edit it myself, and how? Ask for a demonstration on an existing client site, not a promise.
7. What happens after launch? Warranty period for bugs, maintenance options, what an hourly request costs.
8. What do you need from me, and when? A developer who has thought about your obligations has run real projects.
9. Can I speak to a past client? The reaction matters as much as the reference.

Red flags that actually predict trouble

Some warning signs are folklore. These are the ones I'd actually act on:

A quote with no scope attached. A single number and a start date, with nothing describing what you get. Every dispute I've ever heard about traces back to this.

They never ask about your business. If the first call is entirely about pages, plugins and price, and nobody asked who your customers are or what a good month looks like, you're buying construction without architecture.

Yes to everything. Every real project has tradeoffs. Someone who agrees to every request, timeline and budget without pushing back once either hasn't understood the work or is planning to renegotiate later.

Full payment up front, or no payment structure at all. Milestones protect both sides. A deposit is normal; the whole amount before anything exists is not.

Hosting and domain in their name "for convenience." Convenient right until you want to leave.

Slow, vague replies before you've paid anything. This is the fastest they will ever be. Communication doesn't improve after the invoice.

Guaranteed number-one rankings. Nobody can guarantee that. It's a reliable indicator that other claims deserve checking too.

Green flags most people miss

They tell you something you didn't want to hear. "You don't need this feature." "That deadline isn't realistic with the content you have." Being talked out of spending money is the strongest signal you'll get.

They ask about your content early. Content is what delays projects. Someone who raises it in the first conversation has been burned before and learned.

They explain things without jargon or condescension. Understanding something well enough to explain it plainly is not a soft skill — it's the same skill that produces maintainable work.

They have opinions with reasons behind them. "I'd use WordPress here, and here's why Webflow would fight you in year two" beats "whatever you prefer."

They plan for after launch. Backups, updates, a handover video, who to call when something breaks. Developers who think past the launch date build differently before it.

What belongs in the agreement

You don't need a twenty-page legal document. You need a written record of what you both think is happening, because in three months you'll remember it differently. Put in writing:

• The deliverables, itemised — the page list and the functionality, not "a website."
• Revision rounds included, and the rate for work beyond them.
• Payment schedule tied to milestones.
• Timeline, plus what happens when either side causes a delay. Content arriving late is a delay too.
• Ownership of code, design and content on final payment.
• Which accounts are in your name.
• A warranty window for fixing bugs after launch.
• An exit clause: how either side stops, and what gets handed over if they do.

A developer who resists writing the deliverables down has just answered your most important question.

Working well once it starts

Half of a project's outcome is on your side of the table, and it's the half people underestimate.

Deliver content in one batch, early. Text, images, logos, logins. Drip-fed content is the number-one cause of delay on every project I've run, and it's the one delay that also degrades quality — layouts designed around placeholder text get rebuilt around real text.

Consolidate feedback. One document with everyone's comments beats nine separate emails, and it forces your team to resolve their disagreements before they land on the developer as contradictions.

Nominate one decision-maker. Design by committee produces the average of everyone's opinion, which is never anybody's best idea.

Say what's wrong, not what to change. "This section doesn't make me want to book" is more useful than "make the button green." You know your customers; they know the fixes.

Respect scope, or pay for the change. Adding a shop halfway through isn't a small favour, and the projects that go badly are usually the ones where a series of small favours quietly doubled the work.

FAQ

Is it better to hire a freelancer or an agency?

A freelancer gives you direct contact with the person doing the work, faster decisions and lower overhead, which suits most small and medium projects. An agency gives you a team, redundancy if someone leaves, and capacity for large multi-discipline work. The real question isn't freelancer versus agency — it's whether the person you're speaking to is the person who builds. In many agencies, they aren't.

Should I hire a developer who specialises in my industry?

It helps but it's rarely decisive. It matters most in regulated sectors like health or legal, where the constraints are real. Below that, a developer who has solved your type of problem — booking, catalog, multi-branch, multilingual — is more useful than one who happens to have worked in your sector.

What should be in a web development contract?

Deliverables, revision rounds, payment schedule, timeline with delay handling, ownership of code and design, whose name holds the hosting and domain accounts, and how either side exits. See the section above for the full list.

How do I know if a developer's portfolio is really their work?

Ask what specifically they did on two or three projects. Someone who built a site can tell you what was hard, what the client changed halfway through, and what they'd do differently now. Someone who didn't stays vague. Check the sites are still live while you're at it.

The short version

Know what success looks like before you ask for prices. Write one page and send it to three people. Judge portfolios by evidence, not aesthetics. Get the scope in writing. Keep your own accounts. Deliver your content early. And weight your decision towards the person who told you something you didn't want to hear — over eight years, that's the signal that has correlated best with projects that went well.