Red Flags Your Developer Isn't Delivering: A Founder's Checklist

I want to be upfront about something: I'm a developer writing this article about how to spot bad developers. There's an obvious conflict of interest. But I've also spent years inheriting projects from developers who didn't deliver, so I've seen every pattern in this list from the receiving end. And frankly, the founders I work with are better clients because they know what to look for.

So here's the checklist. Print it out, stick it on your wall, refer to it weekly.

Red Flag #1: No Working Demo After Week One

What it looks like: "I'm still setting up the project structure." "I'm working on the architecture." "I need to finish the database design first."

What it actually means: Either they haven't started, they're over-engineering, or they're stuck and won't tell you.

A competent developer can have something clickable — even if it's rough — within a week. A login screen. A form that saves data. A list page that shows records. It doesn't need to be pretty. It needs to be real.

When I started TidyLinker, Adele had a working prototype to click through within the first two weeks. Basic, sure. But she could see actual progress on an actual screen in an actual browser. That's the standard.

What to do: Ask directly: "Can you show me something I can click on by Friday?" If the answer is a qualified maybe or a deflection about architecture, you have a problem.

Red Flag #2: "It's Almost Done"

What it looks like: Monday: "Should be done by Wednesday." Wednesday: "Just fixing a couple of things, end of week." Friday: "Hit a snag, early next week." Repeat for three weeks.

What it actually means: They've done the easy 80% and are drowning in the hard 20%. Or they haven't done 80% and are bullshitting you. Either way, "almost done" without a working demo is meaningless.

Software isn't "almost done" in any useful sense. It either works or it doesn't. A feature is either complete and testable, or it's in progress. There's no almost.

What to do: Change the conversation. Instead of "is it done?" ask "can you show me what works right now?" Force a demo. What you see will tell you more than any status update.

Red Flag #3: Won't Give You Code Access

What it looks like: "I'll hand over the code when it's done." "It's in my personal repo, I'll transfer it later." "You don't need access yet."

What it actually means: One of three things, all bad. They're using code from another client. The code is a mess and they know it. Or they're creating leverage so you can't leave.

Your code should live in a repository you own from day one. Not the developer's personal account. Not "we'll sort it out later." Day one. If you're paying for it, you own it.

I had a conversation with a founder last year who was six months into a project and didn't have code access. Six months. When the developer finally shared it, the code was barely functional — months of "progress" was a handful of partially working files. If the founder had access from the start, they could have had any developer look at it and catch the problem in month one.

What to do: This is a deal-breaker. If your developer won't put the code in a repo you control, stop paying them until they do. Not negotiable.

Red Flag #4: Can't Explain What They're Building

What it looks like: Technical word salad. "I'm implementing the microservice orchestration layer for the event-driven notification subsystem." You nod and feel stupid for not understanding.

What it actually means: Either they don't understand it themselves, or they're hiding behind jargon to avoid accountability.

Good developers can explain complex things simply. "I'm building the system that sends emails when a cleaner accepts a booking." See? Same thing, but you actually know what's happening and can evaluate whether that's the right priority.

What to do: Ask them to explain it like you're 12. Not patronisingly — just clearly. "I don't understand what that means. Can you explain what it does for the user?" If they can't, they're either confused or evasive.

Red Flag #5: Scope Keeps Growing Without Discussion

What it looks like: "I also built a role management system." "I added an analytics dashboard." "I set up a CI/CD pipeline with three environments."

What it actually means: They're building what interests them, not what you need. Or they're padding hours. Or they genuinely think it's needed but didn't check with you first.

Some scope growth is natural. A developer might discover during building that you need a particular piece of infrastructure. But a good developer discusses it first: "I think we need X because of Y. It'll take about Z time. Do you want me to do it now or later?"

A bad developer just builds whatever and presents it as a bonus. It's not a bonus. It's time taken from the features you actually asked for.

What to do: Establish a simple rule: nothing gets built that wasn't agreed upon. New ideas go in a backlog. The developer proposes, you prioritise. If they keep freelancing without discussion, have a direct conversation about it.

Red Flag #6: No Tests

What it looks like: You probably won't know this unless you ask directly. Ask: "How many automated tests does the project have?"

What it actually means: If the answer is zero, or they don't know, or they say "I test manually" — the codebase has no safety net. Every change risks breaking something else. Every deployment is a roll of the dice.

I've said this before and I'll keep saying it: the Rezzy prototype had zero tests. Zero. That's how it ended up with 22 database tables, broken email queues, and dead code everywhere. Nobody could safely change anything because nobody knew what changing something would break.

What to do: Ask for a test count. On any serious project, you should see tests growing with the codebase. If there are none, ask why and when they plan to add them. If the answer is "we'll add tests later" — later never comes.

Red Flag #7: Blame Without Solutions

What it looks like: "Stripe's API is really difficult to work with." "The hosting provider is having issues." "React has a bug that's blocking me."

What it actually means: Sometimes these are genuine issues. But a pattern of external blame usually means the developer is struggling with things they should be capable of handling.

The difference between a good developer and a mediocre one isn't that good developers never hit problems. It's that good developers hit problems and then solve them. "I ran into an issue with Stripe's webhook handling, so I built a retry mechanism with exponential backoff. Here's how it works."

What to do: Listen for the pattern. One external issue? Fair enough. Regular external blame? That's a competence problem disguised as bad luck.

Red Flag #8: Inconsistent Communication

What it looks like: Three days of silence, then a burst of messages. Missed calls without explanation. Replies to easy questions immediately, ignores hard ones.

What it actually means: They're either juggling too many clients, struggling with the work, or both. Inconsistent communication is almost always a symptom of something else.

I'm not saying your developer needs to respond within minutes. I'm saying you should have a predictable cadence. If you agree on weekly updates, you get weekly updates. If you agree on same-day replies during working hours, that happens.

What to do: Set explicit expectations. "I'd like a status update every Monday morning and replies within 24 hours on weekdays." If they can't commit to that, find out why.

Red Flag #9: Resists Process

What it looks like: Doesn't want to use a project board. Won't write things down. "I keep it all in my head." Avoids sprint planning or any form of structured work.

What it actually means: They're either disorganised, used to working without accountability, or hiding the fact that they're not making progress.

Process doesn't need to be heavy. A simple Trello board with To Do, In Progress, and Done columns is enough. But there needs to be something visible that shows what's being worked on and what's finished.

What to do: Insist on minimal process. It protects both of you. If they push back on basic visibility, that's a signal.

What To Do When You Spot These Flags

First: don't panic. Most of these are fixable if caught early. Have a direct conversation. "I've noticed X. Can we talk about it?" Give them a chance to explain and correct.

If the conversation doesn't change behaviour within two weeks, escalate. Get an independent code review from another developer. This costs a few hundred pounds and gives you an objective assessment.

If the review confirms your concerns: cut your losses. It's cheaper to stop now and find someone better than to continue paying for work that isn't being delivered. You own the code (because you insisted on repository access from day one — right?), so you can hand it to someone else.

The founders who get burned worst aren't the ones who hire a bad developer. They're the ones who hire a bad developer and take six months to admit it.

I've been building web products for 16 years. If you're looking for a senior developer you can actually trust, get in touch.