<p>Right, let's talk about the part most "<strong>how to hire a developer</strong>" guides skip, mate: the moment you find out too late. The chat went well. The quote looked fair. You signed. Three months later you're stuck with a site you can't update, don't technically own, and can't get anyone on the phone about. That's not bad luck, that's a spanner someone else built into the works before you ever noticed it, back when everything still looked fine. Most guides on red flags when hiring a web developer stop at "<strong>check their portfolio.</strong>" That's not enough.</p><p><em>Having built sites full-stack and on WordPress for a living, I've seen both kinds of developer: </em>the ones who treat your project like chemistry get the ingredients right, in the right order, and the reaction just works and the ones treating it like a vending machine, money in, website out, never seen again once it's live. The tricky part is that both types sound almost identical in the first conversation.</p><h1>The Real Red Flags When Hiring a Web Developer</h1><p>Here's each one, what it actually means underneath, and the exact question that exposes it before you've signed anything.</p><h2>1. They skip the discovery conversation entirely</h2><p>If a quote lands in your inbox before anyone's asked what your business actually does, who your customer is, or what's currently not working on your existing site that's the first ingredient missing. A quote without discovery is a guess wearing a price tag. A good developer treats that first conversation as the reaction starter, not a box-ticking formality to rush past on the way to invoicing you. What to ask: "Before we talk numbers, can you tell me what you'd want to understand about my business first?" If the answer is a shrug, you've got your answer.</p><h2>2. The portfolio is all templates, no problem-solving</h2><p>Nice screenshots are easy to produce and easy to admire. What you actually want to hear is what problem each project solved fewer support calls, more bookings, a checkout that stopped losing people halfway through, a page that finally loads fast enough for people to stick around. Ask that question directly for two or three of their projects and watch how specific the answer gets. Vague, general answers ("it looks modern, clients love it") usually mean the thinking stopped at visuals.</p><h2>3. Nobody mentions who owns what</h2><p>Here's the bit that trips people up, because it's genuinely not obvious if you haven't been burned by it before: your domain (the actual web address, like yourbusiness.com), your hosting (the server where your site's files physically live), and your CMS admin login (the dashboard you'd use to edit pages yourself) should all be registered in your name, on your own accounts, from day one. If a developer is vague about that, or says "don't worry, I'll manage all that for you," they've quietly kept the keys to your own house. Ask straight out: "Will I have my own hosting account and my own admin login before this goes live?" A good developer answers that fast and specifically. A dodgy one gets vague real quick, or tries to reframe it as extra convenience.</p><h2>4. "Support" is never actually defined</h2><p>Ask what happens the week after launch. A small copy change, a broken contact form, a plugin that needs updating before it becomes a security problem is any of that covered, and for how long? Or does everything quietly become billable the moment the site goes live, with no rate ever mentioned upfront? Vague support terms are how a "finished" website turns into a slow, unpredictable drip of invoices. Get it in writing before you sign: what's included, for how long, and what happens after that window closes.</p><h2>5. Communication goes quiet between milestones</h2><p>A build should feel like an ongoing partnership, not a black box you occasionally knock on and hope someone answers. Long stretches of silence with no proactive update especially once payment's already changed hands is usually a preview of how responsive they'll be after launch, when you actually need them for something urgent. Good developers tell you what's happening before you have to ask.</p><h2>6. They can't explain a decision without jargon soup</h2><p>Ask why the site feels slow, or what "SEO" is actually doing for your business day to day, and if what comes back is a wall of acronyms with zero plain-English translation, that's worth noticing. It's less about whether they know the terms they should and more about whether they can actually partner with you on decisions once things get technical and a call needs to be made. Domain authority, semantic search, whatever the term of the week is: a good developer can say it once, then immediately tell you, in one plain sentence, what it means for your business and your customers.</p><h2>7. The price feels too good, with no explanation</h2><p>If one quote comes in dramatically lower than everyone else's for the same brief, remember: chemistry doesn't work if you quietly leave an ingredient out. Something in that lower price is usually missing proper testing across devices, accessibility for people using screen readers, basic security hardening, or a "support" line that mysteriously doesn't exist once you need it. That's awesome value on paper and a genuine headache six months in. It's fine to ask directly: "Everyone else quoted noticeably more what's different about your process?" A confident answer is a good sign. Dead air isn't.</p><h2>8. There's no real conversation about what happens if you want to leave</h2><p>Every partnership should be able to end cleanly. Ask what the process looks like if you ever wanted to move your site to someone else can you take your content, your files, your access with you? A developer who's built things properly has no problem with that question. One who's built in dependency on themselves will suddenly get uncomfortable.</p><p>None of this is meant to make you paranoid about hiring outside help quite the opposite. It's meant to help you recognise what a genuinely good developer relationship actually feels like from the very first conversation, so the good ones stand out fast and the vending-machine types stop wasting your time. Knowing the real red flags when hiring a web developer is what turns "hope this works out" into an actual decision. If you're sizing up a project brief or a shortlist of developers right now and want a second, no-pressure opinion on either, that's genuinely what I do for a living happy to have a look.</p>

Spot the real red flags when hiring a web developer before you sign ownership, support, and communication issues that cost you later.

Articles

Red Flags When Hiring a Web Developer (And What They Actually Mean)