A good chunk of our work is rescue jobs. A business hires a developer, the project drags or dies, and we get the call afterwards to sort out what is left. After fourteen years of these calls, the failures stopped surprising us — the same warning signs appear again and again, usually visible before any contract was signed.
This is that list. Nine red flags, each one drawn from a real rescue. If you are evaluating a developer right now, run them against it. If they clear all nine, you have probably found someone decent.
1. They quote before they ask questions
You describe your project in two sentences. A price comes back in an hour.
A serious quote needs answers first. What does the site integrate with? Who updates content, and how technical are they? What happens at your busiest time of year? A developer who prices without asking is either guessing high to cover the unknowns or guessing low to win the job — and the low guess becomes a fight later, when the unknowns surface as “extras”.
From a rescue last year: a client accepted a quote produced in 40 minutes for a store with a custom stock system. The quote had assumed standard WooCommerce. The relationship died at the exact moment that assumption did.
2. No questions about your business — only about your website
Related, but different. A developer can ask a hundred technical questions and still never ask what the site is for. What does a lead cost you? Which products carry your margin? What breaks your week if it goes down?
A website is a business tool. Someone who builds it without understanding the business builds decoration. The best predictor we know for a project that ends well: the developer’s early questions make the client think about their own business in ways they had not.
3. Everything gets a yes
Every deadline: yes. Every feature: yes. Budget cut by a third: yes, no problem.
Some of that is politeness. Most of it is a person who has not thought hard enough about your project to see where the trouble lives, or who plans to renegotiate once you are too committed to leave. Real expertise sounds like “yes, but that will cost you speed” and “no — and here is what I would do instead”. If nobody ever pushes back before you sign, expect all the pushback to arrive after.
4. They cannot explain things without jargon
Ask a candidate to explain what a plugin does, or why the quote lands where it does. If the answer is a wall of acronyms, that is not depth — it is a wall.
People who understand something can explain it to a smart non-specialist. And a developer who cannot make themselves understood before the sale will not become clearer when something breaks and you need a straight answer at speed.
5. No access, no ownership, everything through them
The hosting is in their account. The domain is registered to them. There is no admin login for you, “to keep things secure”.
This is how clients end up hostages. When the relationship sours — and the developers who do this are disproportionately the ones it sours with — your website, your domain, and your customer data are bargaining chips. We have negotiated releases more than once, and it is ugly every time.
The non-negotiable baseline: hosting in your account, domain registered to you, an administrator login in your name from day one. A trustworthy developer insists on this arrangement, because they never want to be the hostage-taker in someone’s story.
6. No staging site, no version control
Two questions to ask any candidate: “Where do you test changes before they go live?” and “What happens if today’s change needs undoing next week?”
The answers you want involve a staging environment and version control — the answers you get from professionals without prompting. The answer that should end the conversation: “I edit on the live site, carefully.” Every one of our worst rescue cases — white screens during trading hours, checkouts broken for days — traces back to cowboy edits on production with no way back.
7. The portfolio is all screenshots and no live sites
Screenshots are easy. Live URLs invite you to check: does the site still exist, does it load fast, does the checkout work, is the client still using it three years on?
Ask for live links and — better — for a client you can actually speak to. What you want from that call is not “were they nice” but “what happened when something went wrong”. Every long project hits a problem. How the developer behaved that week tells you everything. We keep our own case studies public and current for exactly this reason.
8. Silence between payments
Watch the communication rhythm during the sales process, because it only degrades after it. Enthusiastic replies until the deposit clears, then a week of nothing? That is the pattern at its best.
What good looks like is boring: a predictable update cadence, honest “this took longer than expected” messages, questions when the spec is ambiguous rather than silent guessing. Boring, reliable communication is worth more than talent over a project’s life. We would rather lose a pitch for saying “that deadline is not realistic” than win it and prove the point in month three.
9. No plan for after launch
Ask what happens the day after the site goes live. Who applies updates? Who takes backups, and has anyone ever tested restoring one? What does it cost to fix a small thing in month four?
“It’s WordPress, it looks after itself” is the wrong answer. Sites need updates weekly, and unmaintained ones accumulate risk quietly — until the day it is not quiet. A developer with no aftercare answer is planning to disappear at launch, leaving you to discover this gap at the worst possible moment. It is the reason we run care plans rather than treating launch as goodbye — and if you want to understand the difference between real upkeep and button-pressing, we broke it down in our care plan versus maintenance comparison.
What to do if you recognise these flags
If you are mid-project with a developer showing three or more of these: secure your access first. Hosting account, domain registrar, an admin login — quietly confirm you hold all three before any difficult conversation. Then get an independent read on where the project actually stands; our free audit is built for exactly that situation, and we will tell you plainly whether the work is salvageable.
If you are still choosing: our guide on how to choose a WordPress developer is the positive version of this post — the green flags, and the questions that surface them.
And if you have already been burned and just need the mess fixed, that is not an embarrassing call to make. It is roughly a third of our inbox. Bring us the broken thing via small fixes if it is contained, or talk to us if it is not, and you will get an honest scope either way.
