7 Signs It's Time to Fire Your Web Developer (And What to Look for Next)

You don't need to know how to code to know when it's time to fire your web developer. The clearest signal is a pattern, not a single bad moment: communication goes quiet for days at a time, the same bug keeps coming back after being "fixed," invoices show up with no warning attached to them, and direct questions get vague answers instead of straight ones. Any one of these on its own might just be a rough week. Three or more of them, repeating over a month or longer, is a pattern — and a pattern is what you fire, not a person having an off day.

If you're reading this because something feels off and you can't quite name it, that instinct is worth taking seriously. Founders in this situation usually feel guilty for even considering a change — worried they're being "difficult," worried they don't understand enough about code to have an opinion, worried a new developer will be worse. Most of the time, none of that guilt is warranted. You hired someone to solve a business problem. If the relationship stops doing that, wanting out isn't difficult. It's reasonable.

Normal project friction vs. an actual red flag

Every project has friction. Scope shifts once you see the first draft. A feature takes longer than estimated because the requirement was underspecified. A developer pushes back on an idea because it will hurt performance. None of that is a warning sign — it's what building something real actually looks like, and a developer who never disagrees with you is often more worrying than one who does.

The test that actually separates friction from a red flag is direction, not intensity. Is the working relationship getting better as the project goes on, or worse? Do problems get acknowledged and fixed, or explained away and repeated? Normal friction resolves. A red flag compounds — the same issue shows up again next sprint, next month, in a different disguise, and you're the one doing the follow-up every time.

7 signs it's time to fire your web developer

1. 01

   Communication goes silent for days or weeks with no proactive update

   A slow reply once in a while is normal. A pattern of silence isn't — it means you've become the project manager on your own project, chasing status instead of receiving it. A developer who's actually in control of the work tells you where things stand before you have to ask. Silence usually means there's nothing good to report, and no plan to fix that.

2. 02

   Every simple request turns into a surprise invoice

   Small changes should have small, predictable costs, and you should generally know the range before the work starts. If a one-line copy change or a button color swap routinely comes back as an unexpected line item, the pricing model is designed to extract money from ambiguity rather than to reflect real effort. That's not how a fixed-scope, trust-based relationship is supposed to work.

3. 03

   They can't explain a technical decision in plain language

   You're not expected to understand code. But any competent developer should be able to explain why a choice was made — why the site is slow, why a feature will take three weeks instead of three days, why a plugin was chosen — in terms a non-technical founder can follow. When the answer is jargon, deflection, or "it's complicated," that's often covering for a decision they can't actually justify, not a genuine complexity gap.

4. 04

   You don't have your own domain, hosting, or CMS credentials

   This is the most serious sign on this list, and the one most founders underestimate. If you can't log into your domain registrar, your hosting account, or your website's admin panel without going through your developer, you don't own your website — they do. This is vendor lock-in, and it turns every future disagreement into leverage against you. A trustworthy developer sets these accounts up in your name from day one and hands you the keys as a matter of course, not as a favor.

5. 05

   The same bugs keep reappearing after being "fixed"

   A bug that returns once might be a genuinely tricky edge case. A bug that returns three or four times, in slightly different forms, usually means the underlying cause was never actually found — only the symptom was patched, quickly, to close the ticket. That pattern tells you something about the quality of the engineering underneath the site, and it will keep costing you time long after you've stopped complaining about it.

6. 06

   Timelines keep slipping without a real revised plan

   One missed deadline is common and forgivable, especially early on. What matters is what happens next: do you get a specific new date, a reason, and a plan to hit it — or a vague "soon" that slips again next week? Repeated slippage with no real re-plan is a sign the original estimate was never grounded in the actual work, and that nothing has changed to make the next one more reliable.

7. 07

   You get defensiveness instead of accountability when you raise concerns

   This is the sign that tells you the most about what continuing to work together will feel like. When you raise a legitimate concern, does the response include ownership and a fix — or excuses, blame shifted onto you, the client before you, or "that's just how it works"? A developer who can't hear feedback without getting defensive won't get better as the stakes go up. That pattern rarely improves on its own.

Why the access issue deserves its own warning

Of the seven signs above, missing access to your own domain, hosting, and CMS is the one to treat differently — it's not just frustrating, it's structurally risky. Without it, you can't switch developers even if you want to. You can't move hosting if the site goes down. You can't update urgent content, respond to a security issue, or prove ownership if a dispute happens. Everything else on this list makes the relationship unpleasant. This one makes leaving it materially harder, which is exactly why it's worth confirming before it becomes the reason you're stuck.

A website you don't have the keys to isn't really yours yet — it's on loan.

How to exit the relationship without burning it down

You don't need a dramatic confrontation to end a working relationship that isn't serving you. A short, professional message stating that you're moving the work to a new team, thanking them for what was delivered, and requesting a specific handover date is usually enough. Keep it in writing, keep it factual, and avoid relitigating every grievance in the message — the goal is a clean handover, not a final argument you win.

Before you consider the relationship closed, get everything back in writing and confirm it actually works — logging in yourself, not just being told access exists.

• Domain registrar login, with you listed as the owner and admin contact
• Hosting or server account access, or a full migration of the site to hosting you control
• CMS or admin panel credentials, reset so the old developer no longer has access
• A full copy of the source code and a link to the code repository, if one exists
• DNS records and any third-party API keys or service accounts tied to the site
• Access to analytics and Google Search Console under your own account

If any of these turn out to be missing or hard to retrieve, that alone confirms the decision to leave was the right one. A developer who resists a reasonable handover request is demonstrating, in real time, exactly the kind of control this list warned you about.

What to vet next time, so this doesn't repeat

The goal isn't just to leave — it's to not end up here again in twelve months with someone new. Before you sign with the next developer or agency, ask directly who owns the domain, hosting, and code once the project ends, and get the answer in writing. Ask how they price change requests, and get a fixed scope instead of an open-ended hourly arrangement that rewards slow work. Ask them to explain one real technical decision from a past project in plain language, on the spot — how well they do that under a little pressure tells you more than any portfolio page. And ask what happens when something goes wrong: the answer should sound like ownership, not blame.

None of this requires you to become technical. It requires the next developer to meet you halfway in plain language, hand you your own keys without being asked twice, and treat a direct question as a normal part of the job rather than an inconvenience. That's a lower bar than it sounds like, and it's the actual bar. If you're vetting a new team and want a second set of eyes on the handover, the contract, or the technical explanations before you sign anything, that's exactly the kind of conversation we're happy to have — no pressure, no pitch, just a straight answer.