How to Hire a Web Developer When You Don't Know How to Code

Hiring a web developer is uncomfortable because you're buying something you can't inspect. If you hire a bad accountant, you'll eventually see it in your books. If you hire a bad developer, everything looks fine right up until you need a change and discover it'll cost more to fix than it did to build.

Here's the good news: you don't need to read code to hire well. Developers who evaluate other developers barely look at code either in a first conversation. They look at how someone thinks, what they ask, and what they promise. You can do all three.

Start with your problem, not the technology

The most common way a non-technical buyer gets a bad outcome is by opening with a solution: “I need a React website” or “I want an app.” You've just handed the developer a specification without telling them what it's for, and now nobody in the conversation is thinking about whether it's the right thing to build.

Open with the problem instead. Three sentences is enough:

“People phone to book appointments and we miss half the calls when we're busy. I want them to book online. I need to see the day's bookings on my phone and I need to stop double-booking the same slot.”

That paragraph tells a developer far more than “I need a booking app” does — and it lets them tell you if there's a cheaper way to solve it. Which brings us to the first thing you should be judging.

Judge these five things instead of code

None of these require you to read a line of code.

1. Do they ask about your business before they quote?

This is the single strongest signal, and it costs you nothing to observe. A developer who gives you a price in the first five minutes hasn't understood what they're pricing. They're quoting a guess, and you'll pay for the guess later when everything you assumed was included turns out to be an extra.

A good first call spends most of its time on questions: who uses this, what do they do with it, what happens today without it, what has to be true on launch day. If nobody asks you those, the quote isn't worth much.

2. Can they explain something technical without jargon?

Ask them to explain a decision in plain English — why they'd build it one way rather than another. Someone who genuinely understands a thing can explain it to you. Someone hiding behind vocabulary usually can't.

This matters beyond the first call. You'll be working with this person for weeks and making decisions based on what they tell you. If you can't follow their explanations now, you won't be able to follow them when something goes wrong.

3. Have they solved a problem shaped like yours?

Not “have they used the same technology” — that's the developer's problem, not yours. Look for a similar shape: a booking flow, a customer database, a payment step, an admin screen where staff manage things.

When you look at their previous work, ask what the client's problem was and what changed after launch. The answer tells you whether they think in terms of outcomes or just features.

4. Do you own everything at the end?

You should own the code, the domain, the hosting accounts and the design files. All of it, in accounts registered to you, from the start of the project rather than handed over at the end.

This is where the worst outcomes happen. If everything sits in the developer's accounts, you can't leave — and once you can't leave, the relationship changes. Ask directly: whose name are the accounts in, and can another developer take this over without you? A confident yes is what you want. Hesitation is your answer.

5. Is the price fixed and in writing before work starts?

For a defined project, you should get a written quote with a number, a scope and a timeline before anyone starts building. Not an estimate that drifts. Not an hourly rate with a vague ceiling.

I quote fixed prices after a free 30-minute call for exactly this reason: it moves the risk of a bad estimate onto me, where it belongs. You approve the scope and the number, then work begins.

Four questions to ask on the first call

Copy these. You don't need to understand the technical content of the answers — you're listening for confidence, specifics and honesty.

• “What could go wrong with this project, and what would you do about it?” — everyone who has finished real projects has a list. A developer who says “nothing, it's straightforward” has either not thought about it or isn't telling you.
• “What's the cheapest version of this that would still be useful to me?” — this tests whether they're on your side. Someone who immediately sees a smaller first version is thinking about your money. Someone who only describes the full build is thinking about theirs.
• “What do I need to give you, and what happens if I'm late?” — client-side delays such as copy, photos, logins and feedback are one of the most common reasons projects slip. A developer who has been burned by this will have a clear answer.
• “What happens after launch if something breaks?” — you want a defined support window and a clear statement of what happens after it. Any specific answer beats a friendly “just message me.”

What a fair quote includes

You can check every item on this list without technical knowledge. If one is missing, ask why — the answer is informative either way.

• A fixed number and a timeline, in writing, before work starts
• A clear scope — a list of what's included, and ideally what's explicitly not
• Accounts in your name — code repository, domain, hosting, database
• A link you can click before launch to see work in progress on a test version
• A defined support period after launch, with what's covered
• A number of revision rounds, so “one more change” doesn't become an argument
• What it costs to keep running — hosting, domain renewal, any paid services

That last one catches people out constantly. A website isn't a one-off purchase; it has small ongoing costs. A developer who tells you that upfront is being straight with you.

Red flags when hiring a web developer

• A price with no questions — the most reliable warning sign there is.
• A quote dramatically below every other quote — the gap is almost never efficiency. It's scope, and you'll pay for the missing pieces individually later or live without them.
• No written contract for a project of any real size — this protects you more than it protects the developer.
• Pressure to decide quickly — any developer worth hiring has enough work to let you think for a few days.
• They can't show you anything — a personal project is a fine answer when starting out. “It's all under NDA” for an entire career is not.
• They won't put you in touch with a past client — one reference conversation tells you more than an hour of portfolio browsing.

Test someone cheaply before you commit

The best way to reduce risk isn't a longer interview — it's a smaller first job. Pay someone for a few hours of real work before you hand them a twelve-week project: a small fix, a page, or a written review of what you already have.

In that small job you'll learn everything the interview couldn't tell you. Do they reply within a day? Do they explain what they did? Do they finish when they said they would? Do they tell you when they hit a problem, or go quiet? That's the actual working relationship, and a few hundred dollars is a cheap way to find out.

What to prepare before you talk to anyone

Write one page. It doesn't need to be formal and it saves you real money, because it lets developers quote a number instead of a range:

• The problem — what's not working today, in your own words
• Who uses it — customers, staff, admin; and what each of them does with it
• The one thing it must do on launch day for the project to have been worth it
• Your budget range and deadline — both real, not anchoring numbers

Some buyers hide the budget, thinking they'll get a lower price. It usually costs them time instead: without a number, developers quote the full build, and you spend two rounds discovering what you could have had for what you were willing to spend.

Frequently asked questions

A few things people ask before their first call:

Do I need to understand the technology they use?

No. You need to understand what it will do, what it costs, how long it takes, and what happens if you want to change developers. The stack is the developer's concern — it only becomes yours if they choose something so unusual that nobody else can maintain it, which is a fair question to ask directly.

Is a freelancer or an agency safer?

A freelancer is usually cheaper because there's no account manager or project manager layered on top. An agency gives you continuity if one person leaves. For a small business project, a freelancer who communicates clearly and gives you ownership of everything is a good trade.

How do I know if the price is fair?

Get two or three quotes and compare what's included, not the totals. Two very different numbers for “the same” project usually means two very different scopes.

What if I don't know exactly what I want yet?

That's normal and it's fine. Bring the problem and let the developer help shape the solution — that's part of what you're paying for. What you shouldn't do is sign a fixed-price contract while the scope is still vague; agree the discovery first, then price the build.

The short version

You're not evaluating code. You're evaluating whether someone asks good questions, explains things clearly, gives you ownership, and puts a number in writing. Those four things are all visible to a non-technical buyer in a single conversation — and they predict outcomes better than any technical test you could run.

If you'd like to try that conversation with no strings attached: book a free 30-minute call. You'll get honest answers about scope and a fixed written quote, and if your problem doesn't need a developer at all, I'll tell you that too.