How to vet a freelance web developer before you pay a deposit

Learning how to vet a freelance web developer matters because the quotes you get back will vary wildly, the work is hard to judge from the outside, and most of the risk sits with you the moment you pay a deposit. This is a practical checklist: what to look at, what to test yourself, and what has to be in writing before any money changes hands.

Where do I start?

Start with three things in parallel: their portfolio, a live test of one or two of the sites in it, and a short call where you ask how they work. You are looking for consistency between what they say, what they have shipped, and what they will commit to on paper. If any two of those three don't line up, that is your answer.

How do I check the portfolio is real and actually theirs?

Open the live sites, not just the screenshots. Confirm the developer's name or studio appears somewhere credible — a footer credit, a case study on their own site, a LinkedIn post from the time of the build. Ask which parts they personally did: design, build, content, or all of it. A freelancer who did the front-end build on a team is fine; one who is passing off a template demo or someone else's work is not.

What should I test on their past sites myself?

Run a free Lighthouse report on two of their live projects. Lighthouse is an open-source tool built into Chrome (and available through PageSpeed Insights with just a URL) that scores Performance, Accessibility, Best Practices, and SEO [1]. You are not looking for perfect scores; you are looking for someone who clearly cares about them. Also open the sites on your phone, check that forms work, and see whether the pages respond quickly — a slow first response is often a sign of cheap hosting or a heavy, unoptimised build [2]. Our piece on why a slow page loses the sale covers why this is worth your five minutes.

What questions separate a professional from a hobbyist?

• How do you handle SEO basics? A competent developer can talk about titles, meta descriptions, clean URLs, and alt text without prompting — the ground Google's own SEO Starter Guide covers [3].
• How do you approach accessibility? You want to hear the phrase WCAG, or at least a clear commitment to keyboard use, colour contrast, and alt text [4].
• What happens after launch? Updates, backups, security patches — is there a plan, and what does it cost? See the launch checklist.
• How do you handle changes mid-project? A good answer involves a written scope and a change process, not "sure, no problem" — see how scope creep actually happens.

Who owns the website when it's finished?

You should, but only if the contract says so. In the US, work by an independent contractor is not automatically "work made for hire" — website and software work fall outside the statutory categories, so without a written and signed agreement (or a copyright assignment clause), the developer can retain ownership of what they built [5]. Make sure the contract assigns all deliverables, source files, and design assets to you on final payment, and that you get the domain and hosting logins in your own name.

What has to be in the contract before I pay a deposit?

• A written scope. Pages, features, number of revision rounds, and what is explicitly out of scope.
• Ownership and handover. IP assignment on final payment, plus source files, accounts, and passwords in your name [5].
• A timeline with milestones. Dates you can hold them to, and what happens if they slip.
• Payment terms. Deposit amount, milestone payments, and a final payment tied to handover — not to a vague "done".
• A kill clause. How either side exits, and what you keep and pay for if you do.

How should the payment be structured?

Never pay 100% up front. A common structure is a deposit to book the work, one or two milestone payments tied to visible progress, and a final payment on handover. Written contracts are also increasingly a legal expectation for freelance work — for example, in several US jurisdictions a client hiring a freelancer for more than $800 of work must provide a written contract and pay within 30 days of completion unless the contract states otherwise [6]. If a developer resists putting payment terms in writing, that is the whole review right there.

What are the communication red flags?

Slow or vague replies during the sales stage (it does not get better after you pay), reluctance to give references, pushing for the full amount before starting, no written scope, and dismissiveness when you ask basic questions. A developer who explains trade-offs in plain language and writes things down is worth more than one who is simply the cheapest.

Should I ask for references, and what do I ask them?

Yes — one or two past clients, ideally businesses similar to yours. Ask: did the project finish roughly on time and on budget, how were changes and disagreements handled, and would you hire them again. Then ask the one that matters most: what would you do differently if you were starting this project over. The honest answer to that tells you more than a testimonial ever will.

Freelancer, studio, or agency — how do I choose?

A solo freelancer is often the best value for a straightforward site, but you carry the risk if they get sick or overbooked. A small studio costs more but has continuity and a wider skill set. A large agency has the most process and the highest price, and you may not get their senior people. Match the choice to the project's complexity and how much of the risk you want to hold — our cost breakdown shows how the three tiers actually price.

What are the biggest red flags overall?

• No written contract or scope. Everything else depends on this.
• Won't assign IP or hand over accounts. You would be renting your own website [5].
• Full payment demanded up front. Structure it in stages instead [6].
• Portfolio that doesn't check out. Dead links, no credit, or obviously template work.
• Can't explain choices in plain English. If they can't teach it, they may not understand it.

What if it goes wrong after I've paid?

This is exactly why the contract and the staged payments matter. If work stalls, put the problem in writing, reference the scope and timeline, and set a clear deadline. If you built in a kill clause, you can end the engagement and keep what has been delivered and paid for. Withholding the final payment until handover is your main leverage — which only works if you never paid it all early. If you would rather not manage any of this, we build sites on fixed scope with a written handover, and you can send us a quote to sanity-check first.