The biggest red flags when hiring a web developer: no written scope or fixed quote, no real portfolio, vagueness about who owns the code, slow or unclear communication, and a price that's too good to be true. Each one predicts trouble — surprise invoices, an unfinished site, or code you can't take elsewhere. A good developer is clear about scope, price, ownership, and timeline before you pay anything. Watch closely for who isn't.
What are the clearest warning signs?
A few that reliably predict pain: no written scope or quote (just a vague "sure, I can do that"), no portfolio or references, dodging questions about code ownership, and communication that's already slow before you've paid. Add "a price far below everyone else," which usually means corners get cut or the project gets abandoned halfway. None of these are about raw skill — they're about whether the basics of a professional engagement are in place. One subtle sign worth naming: a developer who can't explain their plan in plain language. If everything is buzzwords and you leave the conversation unsure what you'll actually get, that vagueness usually carries straight into the project. Clear thinking shows up as clear talking.
Why does code ownership matter so much?
Because if you don't own your code and accounts, you're locked in. Some developers keep the code, the hosting, or the domain in their own name, so leaving means losing your site. Before hiring, confirm in writing that you'll own the code, the repository, and every account. A developer who won't put that in writing is the reddest flag there is — I cover the stakes in who owns your website code. Ownership isn't a detail; it's the whole point. A quick test before you sign: ask "when it's done, do I own the code, the repo, and every account in my name?" The right answer is an immediate, unqualified yes. Hesitation, conditions, or being told the hosting can only stay in the developer's own name are all signs you'd be renting your own product instead of owning it.
How can you vet a developer up front?
Ask for three things: a written scope and quote, a portfolio of real shipped work, and a clear statement on ownership and handover. Then watch how they communicate while answering — responsiveness now is the best preview of responsiveness later. Good developers welcome these questions because they've already thought them through. The ones who get defensive or vague are telling you how the whole project will go. Believe them early and act on it. It also helps to ask how they handle things going wrong — a missed bug, a change of plan, a delay. Someone who talks openly about process and mistakes is far safer than someone who claims nothing ever goes wrong. Real builds hit snags; what matters is whether they're handled in the open.
Is a cheap quote always a red flag?
Not always — but a quote far below everyone else almost always means something's missing. Sometimes it's inexperience (the person underpriced because they don't yet know what the work involves), sometimes it's corners that won't show until later (no testing, no error handling, code you can't maintain), and sometimes it's someone who'll take the deposit and lose interest halfway. The honest read is that price tracks scope and quality: a number that seems too good usually has a smaller or lower-quality scope hidden behind it. Compare quotes on what's actually included, not only the total — and treat a price with no written scope as no quote at all.
What questions should you ask before hiring?
A short list separates the professionals from the risks:
- What's the written scope, and what's explicitly not included?
- Is this a fixed price or hourly, and what happens if scope changes?
- Do I own the code, the repository, and all accounts when it's done?
- Can I see real, shipped work and talk to a past client?
- What's the timeline, and what do you need from me to hit it?
- How do you handle bugs and changes after launch?
The answers matter, but so does how they're answered. A good developer responds to all of these clearly and without defensiveness, because they've thought them through already. Anyone who dodges, gets vague, or treats fair questions as an insult is showing you exactly how the project will go.
How do I work to avoid these?
I put scope, price, ownership, and timeline in writing before any work starts, and you own everything — code, repository, and accounts — by default. That's the standard behind my services, because trust comes from clarity, not promises. Hiring well is mostly about insisting on the basics up front; any developer worth hiring already works that way. If they won't, that's your answer — keep looking.
Related strategy guides
See freelancer vs agency vs studio, how to write a project brief, and who owns your website code.
Vetting someone for your build? Tell me what you're building — I'll tell you straight what to ask and what to watch for.
