Signs you hired the wrong developer
The clearest signs you hired the wrong developer or agency are simple to spot once you know them: you are over budget with no warning, updates have gone vague or silent, you cannot get your own source code, the senior you were sold has vanished behind juniors, and nobody can explain what was actually built. Most of these are recoverable if you move early. This guide names each sign in plain language, tells you what it really means, and gives you the steps to take now, starting with getting your repo and a second opinion.
01 / Read the signs early
Bad developer relationships rarely blow up overnight. They drift.
The founders who get burned the worst are usually the ones who saw a small warning sign, told themselves it was normal, and waited. By the time the invoice was scary or the calls went quiet, they had already lost months and leverage. You do not need to become technical to catch this. You need to know which behaviors mean trouble and act while you still hold the cards.
The most expensive mistake is staying loyal to a sunk cost. Money already spent is gone. The only question that matters is what protects the business from here. Below is the table to keep next to you.
02 / The red-flags table
The sign, what it means, what to do.
Match what you are seeing to a row. Each one has a clear next move.
| The sign you see | What it actually means | What to do |
|---|---|---|
| You are over budget with no heads-up. | They are absorbing changes silently and billing you later, or padding hours. You carry their uncertainty. | Demand a written, agreed number and date going forward. Price new asks as change orders you approve, not surprises. |
| The deadline keeps moving. | There was never a fixed scope. A range is a way to never be wrong, and it leaves you unable to plan. | Ask for a fixed deadline tied to written acceptance criteria. If they cannot give a date, that is the answer. |
| Updates went vague, then quiet. | You are being managed, not informed. Ghosting usually means the work is stuck and they would rather you not look. | Ask to join the standups and see the working repo this week. Silence after that request is decisive. |
| You cannot access your own code. | The repo lives on their account. You do not own the build, and they know it gives them leverage over you. | Request repository, deployment, and docs access in writing today. This is the most urgent one. |
| The senior you were sold disappeared. | Hidden juniors are doing the work at senior prices. The pitch was the product. Nobody accountable is on the call. | Ask who wrote a specific feature and have them explain it live. Insist on one named senior who owns the result. |
| Nobody can explain what was built. | No documentation, no tests, no clear architecture. It may run today and be impossible to change or hand off tomorrow. | Get a paid audit to read the code and tell you what is salvageable before you spend another dollar. |
| They get hostile when questioned. | A partner who treats reasonable questions as threats is protecting something. This is how code gets held hostage. | Stop adding scope. Secure your access and ownership first, then get an independent second opinion. |
Seeing more than one row? Start a conversation and we will read the situation with you.
03 / What to do now
Three moves, in order. Do them before you fire anyone or sign anything new.
- 01Today
Get your repository, in writing.
Before anything else, secure access to the source code, the deployment, and the documentation. Ask in an email so there is a record. If you own the repo, every other option stays open and switching is a ramp, not a rebuild. If you cannot get it, you have found the real problem, and getting it back becomes the priority over everything else.
- 02Week 0–1
Get an independent second opinion.
Do not decide blind and do not let the same people who built it grade their own work. A short paid audit reads the actual code, maps the security and risk, and gives you a salvage-or-rebuild call in plain language. This is exactly what the Spark audit is for: one to two weeks, the fee credited in full toward any build, and an honest read on whether to keep going, switch, or start over.
- 03Before code resumes
Define done, in writing.
Most of these problems trace back to a project that never agreed what finished looks like. Whoever continues the work, write down the acceptance criteria, the fixed price, and the deadline before code resumes. With "done" defined, you can hold a real commitment instead of arguing about whether the work is finished. Our guarantees are built on signed acceptance criteria for this reason.
Not sure how to vet whoever comes next? Read how to vet a software development agency.
04 / What a good partner looks like instead
The opposite of every red flag above is the bar you should hold for the next one.
- + A fixed price and a fixed deadline, agreed in writing before any code is written.
- + You own the repo, the docs, the prompts, the evals, the deployment, and the IP from the first line.
- + One named senior is accountable for the result and shows up on the calls, with no hidden juniors.
- + New asks become change orders you approve, so there are no surprise invoices.
- + A written delivery guarantee against signed acceptance criteria, so "done" is not an argument.
- + You can join the standups and see the working code whenever you want.
That is how we work. See our services or read the guarantees in full.
05 / Common questions
What is the single biggest red flag that I hired the wrong developer?
You cannot get your own source code. If the repository lives only on the developer's account, you are not the owner, you are a tenant. Everything else (slipping dates, vague updates, surprise invoices) is recoverable. Losing access to the code is the one that can strand the whole business. Ask for repository access today, in writing. A good partner gives it without friction. If they stall, treat that as your answer and get a second opinion.
My project is over budget and behind schedule. Does that mean I hired the wrong person?
Not by itself. Scope changes and honest surprises happen on real projects. The red flag is not the slip, it is how it was handled. Were you told early, with a revised number and date you agreed to? Or did the overage show up on an invoice with no warning? A developer who absorbs every change silently and bills you later is the problem. One who flags it, prices it as a change order, and lets you decide is doing the job. If you cannot tell which you have, an audit will read the work and tell you.
How do I know if my agency is using hidden juniors?
Look at who shows up. If the senior you were sold appears in the pitch and then disappears from the standups, the work is likely being done by people you never met. Ask to join the working sessions, ask who wrote a specific piece of code, and ask for it to be explained. Vague answers, constant rerouting through an account manager, and code that nobody on the call can walk you through are the signs. You are paying senior rates. You should see senior judgment.
Can I switch developers in the middle of a build?
Yes, if you own the code. That is exactly why ownership matters. If the repository, documentation, and deployment are yours, a new team can pick up where the last one left off after a short ramp. If they are not, switching can mean rebuilding from scratch. Before you switch, get a paid audit so the next team starts from a clear map of what exists, what is salvageable, and what needs to be redone. That turns a panicked handover into a planned one.
What should I do first if I think I hired the wrong developer?
Get your repository access in writing, then get a second opinion before you make any big move. Do not fire anyone or sign anything new in a panic. A short paid audit reads the actual code, tells you what is salvageable and what is not, maps the security and risk, and writes down what "done" should mean. With that in hand you can decide calmly: keep going, switch, or rebuild. Start a conversation and we reply within a day with a fixed price and a date.
Last updated June 2026 · Talk with Felipe
Your build
Taking on new builds
Have something in mind?
Tell us what you're making. We reply within a day with a fixed price and a date.