5 Signs It's Time to Fire Your Web Developer (and 2 Signs the Problem Is You)

23 September 2026·5 min read

Quick answer: Genuine red flags include weeks of silence, refusing to hand over admin access, and a site that breaks after every small update. But sometimes the real issue is scope changing constantly or refusing to pay for proper hosting and maintenance. Work out which side the problem is on before you jump ship. 🌴

Every agency has heard some version of this call: "our developer's gone quiet and we don't even know if we can get into our own website." It's a genuinely awful position to be in. But here's the less comfortable half of the story — sometimes the developer isn't the problem. Sometimes it's a client who's changed the brief four times without extending the timeline, or who's still on the cheapest hosting plan going and wonders why the site keeps falling over. Before you fire anyone, it's worth an honest look at both sides, because the fix for "bad developer" and the fix for "unclear expectations" are completely different. 💖

What most businesses get wrong

They treat every website problem as a competence problem. A slow response, a bug after an update, a quote that feels high — these can come from a developer who's genuinely not up to the job, or from a working relationship that was never set up properly: no clear scope, no agreed hosting standard, no defined response times. Firing a developer without fixing the underlying setup issue just means round two with someone new, same friction, different invoice.

The diagnostic checklist: which side is the problem on?

Genuine red flags (developer side):

No response for two-plus weeks with no explanation, on more than one occasion
Refuses to give you admin/owner access to your own site, domain or hosting account
The site breaks or goes down after routine updates, repeatedly
Invoices arrive with vague line items you can't map to actual work
No backups exist, or they can't tell you when the last one was taken

Honest self-checks (your side):

You've changed the brief or scope significantly more than once without adjusting timeline or budget
You're on the cheapest hosting available and refuse to pay for anything better
You expect same-day turnaround on requests sent at 11pm on a Friday
You've never actually agreed on response times, so "slow" is your impression, not a broken promise

Score it honestly: two or more genuine red flags with zero or one self-check items = time to move on. Mostly self-check items = fix the relationship setup before you fix the relationship.

A local service business locked out of their own site: their developer had built the site under his own hosting account with no client login at all. When he stopped responding, they had no way in — not even to update a phone number. That's a clean, unambiguous red flag: you should always hold admin access to your own domain, hosting and CMS, full stop.

A B2B firm frustrated by "slow" turnaround: on closer look, they'd never agreed on response times in the first place, and were sending new requests weekly while the previous ones were still in progress. The developer wasn't slow — the workload had never been scoped. A proper statement of work fixed more than a new developer would have.

A retail business whose site broke after every update: three times in four months, checkout went down after a "small" change. No staging environment, no testing before changes went live, and no proactive communication when it happened. That's squarely a competence issue, not a client-expectations one — a professional developer tests before pushing to a live store.

How to actually make the call

Run the checklist honestly, ideally with someone else on your team weighing in too — it's easy to be too generous or too harsh when you're the one who's frustrated. If it's genuinely the developer, secure your access to everything (domain registrar, hosting, CMS admin, analytics) before you say anything. If it's genuinely you, have a direct conversation about scope and hosting standards before assuming a new developer will behave differently under the same conditions.

💡 Always hold your own admin access, no matter how the relationship is going. This isn't a trust issue, it's basic business hygiene — the same way you'd never let one person hold the only key to your shopfront. A good developer won't be offended by the request; a defensive reaction to it is itself worth noting.

Mistakes to avoid

Firing a developer without first securing access to your domain, hosting and CMS
Assuming a new developer will fix problems that were actually caused by unclear scope
Refusing to pay for decent hosting, then blaming the developer for downtime
Never putting response-time expectations in writing, then judging against an assumption
Waiting until you're already locked out to ask "wait, who actually owns this account?"

Frequently asked questions

What if I don't know who has admin access to my own site?

Find out now, before anything goes wrong. Ask your current developer directly for domain registrar, hosting and CMS admin logins — a professional will hand these over without issue. If you meet resistance, that alone is worth paying attention to.

Is it reasonable to expect same-day responses from a web developer?

Generally not, unless you're paying for a support retainer that specifically guarantees it. Most working relationships run on a 24–48 hour response window for non-urgent requests — worth confirming what you've actually agreed to before judging turnaround as too slow.

How do I avoid this problem with the next developer?

Get a written scope of work, agreed response times, and confirmed admin access as standard terms before work starts — not as an afterthought once trust has already broken down once.

Can a good developer still have a site break after an update?

Occasionally, yes — no developer gets it right 100% of the time, and a single hiccup isn't automatically a red flag. What matters is whether they test changes before pushing them live, have backups ready, and communicate quickly when something does go wrong. It's the pattern that tells you which side the problem is on, not one bad day.

Keep reading 🤍

Written by

Kate, founder of Chronically Online

I help Gold Coast and Brisbane businesses grow with branding, websites and marketing that actually works.

Work with me ✦