How to Choose a Freelance Web Developer

You're not evaluating skill. You're evaluating judgment.

Most advice on hiring a developer tells you to check their technical skills. That advice is useless if you're not technical, because you have no way to verify the answer. If someone tells you they're strong in React and Node, you can either believe them or not. You can't test it.

So stop trying. In my experience the projects that go wrong rarely go wrong because someone couldn't write the code. They go wrong because someone didn't ask what happens when a payment fails, didn't mention a delay until the deadline had already passed, or agreed to a scope they hadn't understood.

Those are judgment and communication failures, not skill failures. And unlike skill, you can assess both of them directly, in the first conversation, without knowing a single line of code.

Read the portfolio for problems, not pictures

A portfolio of screenshots tells you that something looked finished once. It doesn't tell you who built it, what was difficult, or whether it still works.

What you want instead is a description of a problem and how it was solved. Not "built an e-commerce site," but what the constraint was, what approach was chosen, and what was traded away. Anyone who has genuinely shipped something can describe the part that was hard, because they remember it. Anyone who has mostly assembled templates will stay at the level of features and adjectives.

Three specific things to look for when you read case studies, including mine:

• Is their own role stated? "We delivered" can mean they led the build or wrote one page of it. A credible write-up says which parts were theirs.
• Are the difficulties named? A case study with no obstacles in it is marketing copy. Real projects have a section where something didn't work the first time.
• Are the claimed results plausible? Round, dramatic numbers with no method behind them are usually decorative. A developer who says "this part we measured, this part we didn't" is being more careful with your money, not less confident about their work.

If you see work that resembles your project, ask what they'd do differently now. The answer separates people who reflect on their work from people who repeat it.

Your brief is a filter. Use it as one.

Write down what you need in a few paragraphs: what the thing does, who uses it, what has to exist on day one, and what can wait. Send the same text to everyone you're considering.

Then judge the replies, not just the quotes. You are running a small test, and it is remarkably predictive:

• Who asked questions before quoting? Any brief short enough to read in a minute is too short to price accurately. Someone who quotes instantly either hasn't thought about it or intends to renegotiate later.
• Did they push back on anything? A developer who tells you one of your requirements is more expensive than it's worth, or that something simpler would serve you better, is going to keep telling you useful things after you've paid them.
• Did they understand the business, not just the feature list? The reply that restates your goal in their own words, correctly, is worth more than the one that lists technologies.
• How long did they take, and did they say so? Nobody owes you an instant reply. But "I'll come back to you on Thursday," followed by a reply on Thursday, is a preview of the whole project.

The same brief also makes the quotes comparable. If two responses land far apart, that gap is almost always about scope rather than greed, which is a subject I've written about separately in what actually drives the cost of a freelance project.

Signals that predict trouble

None of these are automatically disqualifying. Each one is worth a direct question, and how the question lands tells you as much as the answer.

• Agreement with everything. If nothing in your brief drew a single caveat, a question, or a suggestion, you're talking to an order-taker. Order-takers build exactly what you described, including the parts you got wrong.
• A price with no written scope. A number alone is not a quote. Without a definition of what's included, every disagreement later becomes your word against theirs.
• Vagueness about who does the work. Subcontracting isn't inherently a problem. Discovering it halfway through is. Ask directly whether anyone else will touch the code.
• No questions about hosting, domains, or what happens after launch. A developer thinking only up to handover has not thought about you using the thing.
• Reluctance about code ownership. Ask whether you receive the source, assets, and credentials at the end. Any hesitation here is the single most expensive red flag on this list, because it determines whether you can ever hire anyone else.
• Pressure to decide quickly. Genuine availability constraints exist and get explained calmly. Urgency used as a closing technique is a sales tactic, and it predicts how the rest of the relationship will feel.
• Guaranteed search rankings. Nobody controls Google's results. A guarantee of position one is either a misunderstanding of how ranking works or a deliberate lie, and neither is what you want managing your site.

Signals that predict a good project

These are quieter, and easy to miss because they don't feel like selling:

• They ask what happens when things fail, not just what happens when they work. Payments decline. Uploads time out. Two people edit the same record. Someone who raises these unprompted has run software in production.
• They tell you what they won't do, or aren't the right person for.
• They describe a process: how scope is agreed, how changes are priced, when you'll see progress, what the milestones are.
• They write clearly. Clear writing about a project is strongly correlated with clear thinking about it, and you are going to be reading their updates for weeks.
• They're straightforward about limits. A solo freelancer cannot offer round-the-clock cover, and saying so is more reassuring than an SLA nobody intends to honour.

Freelancer, agency, or marketplace

These are genuinely different trade-offs, and the right answer depends on your project rather than on which is better.

An agency gives you continuity and cover. People are replaceable within the team, someone is always reachable, and there's a process around the work. You pay for that overhead, and the person who impressed you in the pitch is often not the person who writes your code.

An independent freelancer gives you direct access to the person building the thing, faster decisions, and no account-management layer. The risks are real and worth naming: one person has finite hours, gets ill, and can only be in one project at a time. Ask how they handle competing deadlines and what happens if they're unavailable mid-build.

Marketplaces lower the cost of finding someone and add an escrow layer, which has value if you've never hired before. They also optimise for speed and price, which is why briefs on them tend to get quoted rather than questioned. Vetting still falls to you, so everything above still applies.

For most small teams the real question isn't the category. It's whether the person you'll actually be talking to has built something like this before, and whether they're honest about the parts they haven't.

Questions worth asking on the first call

Fifteen minutes is enough. These are about fit and competence rather than price:

• What's the closest thing to this you've built, and what went wrong on it?
• Which part of my project do you think is the riskiest?
• What would you need from me, and when, to avoid blocking you?
• How will I see progress before the end, and how often?
• What's out of scope as you understand it today?
• Who else is involved, and what are you working on in parallel?
• What happens after launch if something breaks at an inconvenient hour?

The second question is the most revealing one on the list. A developer who can immediately name the riskiest part of your project has already thought about building it. A developer who says it's all straightforward has not.

Settle these in writing before any work starts

None of this requires a lawyer or a long contract. An email both of you have agreed to is enough, and it prevents most of the disputes that actually happen:

• Scope. What's included, and an explicit list of what isn't.
• Ownership. You receive the source code, design assets, and all credentials at handover. State it plainly.
• Milestones and payments. What's delivered at each stage and what's paid against it. Payment tied to delivery protects both sides.
• Revisions. How many rounds are included, and what counts as a revision rather than a new requirement.
• Change handling. How a mid-project change gets priced and scheduled. Changes are normal; unpriced changes are where resentment comes from.
• Accounts in your name. Domain, hosting, and any third-party services registered to you, with the developer added as a collaborator. This is the difference between switching developers and starting over.
• After launch. What support is included, for how long, and what ongoing maintenance costs if you want it.

Where I'd tell you to hire someone else

Applying all of this to myself, since it would be strange not to.

I'm one person. I can't offer 24/7 cover, and I won't claim otherwise. If your system genuinely needs someone reachable at three in the morning, you need a team, and I'd say so on the first call rather than three weeks in.

I don't do brand identity, illustration, or heavy visual design work. I build things that work well and look clean, and for anything past that you want a designer.

What I'm actually good at is the part most people can't see: backend logic, payment and API integrations, cloud infrastructure, and the failure cases that only show up once real users arrive. If that's the shape of your project, the services pages set out how each kind of engagement runs, and the case studies describe what the hard parts actually were.

The short version

Send the same written brief to everyone. Judge the replies as carefully as the quotes, because the reply is a free sample of how they'll communicate all the way through. Read portfolios for problems rather than pictures. Ask what the riskiest part is. Get scope, ownership, and milestones in writing before anyone starts.

You can't verify that someone is a good developer. You can verify that they think clearly, communicate honestly, and tell you things you didn't want to hear. That's most of what separates a project you're glad you did from one you're still untangling a year later.