12 signs your dev team is failing you.
Repeated delivery, communication and access problems are reasons to investigate your development engagement. Use these twelve questions to collect evidence, understand the cause and choose a practical next step.
By Twin Designs & Tech · Updated · All guides
Money signs
The invoices say more than the demos.
Compare what you have spent with the work you agreed and the evidence delivered. These questions help you tell a scope change from a delivery problem.
1. The budget grows but the demo does not
Ask to see the agreed changes working in the current release, next to the work you were billed for. If the product has not moved, find out whether the time went into discovery, a blocked dependency or rework. The explanation should tie the spending to evidence you can review.
2. Every small request becomes a change order
A change order can be fair when the requirements have changed. Ask whether the request was in the agreed scope, what changed and how the estimate was approved. If you keep arguing about the same boundary, the scope or the change process probably needs fixing.
3. The estimate to finish never shrinks
Compare the estimate of remaining work against the same scope each time. New requirements can raise it, and completed work should show up in a working release. Ask the team to explain what was added, what was removed and which assumptions are still open. A percentage will not tell you that.
4. Staffing and review responsibilities are unclear
Ask who does the work, who reviews it and who is accountable for the release. A change of people is not a problem in itself, but repeated handovers with no continuity or review can slow delivery. Compare the staffing you have with what the agreement says.
Delivery signs
Missed deadlines need context and a credible next plan.
One missed date needs an explanation. Repeated misses mean you should review the plan, the dependencies and the evidence behind the progress reports.
5. Sprint commitments are missed again and again
Look at the pattern of commitments and the reason given for each miss. Ask what changed in scope, capacity or dependencies, and how the next plan allows for it. A recovery plan needs milestones you can see and an owner. A new date with nothing behind it is not one.
6. "Done" breaks the moment users touch it
Ask to test the agreed journey with realistic data and the exceptions you expect. A demo where everything goes right can hide missing validation, access rules or integration behavior. Write down the failures you can reproduce, and check that fixes are retested in the deployed version.
7. Nobody can tell you what is actually left
Ask for a written list of launch requirements, open defects and decisions still to be made. The team should separate required work from optional ideas and say what it does not know yet. A vague percentage cannot tell you what to do next to get the product closer to release.
8. Updates arrive late, thin, or only when you chase
Agree how often you will get updates, a named contact and the evidence each update should include. If updates are still late or unclear, ask what is getting in the way. A communication problem needs a specific fix of its own, alongside the technical work.
Control signs
Control questions start with who holds the keys.
Ownership, recovery and documentation decide how well your business keeps running through a change of staff or vendor.
9. You do not have admin access to your own product
Confirm who owns the source, hosting, domain and important provider accounts. Your business needs recovery access and a lasting owner. Write down what any transfer depends on, and check the real account permissions. A shared login may not be enough.
10. The documentation could not survive the team leaving
Ask another authorized engineer to run and deploy a test version from the written instructions. Missing configuration names, undocumented jobs and unexplained manual steps are gaps in the handover. Write them down and get them fixed while the current team is still available.
11. Technical questions get answered with jargon instead of English
Ask what the issue means for the user, what the options and tradeoffs are, and what evidence you need to choose. You should be able to understand why a recommendation matters without learning the whole codebase. If the explanation is still unclear, ask for a written decision note.
12. Concern is growing without a clear decision
Concern is a reason to investigate. On its own it is not a diagnosis of failure. Write down the specific things you have seen, ask for the team’s response and compare it with working evidence. An independent assessment can help when what you still do not know affects a major decision.
Seeing a repeated pattern? Here is what to do this week.
- Confirm business-controlled access to source, hosting, domain and store accounts, including recovery contacts and any handover dependencies.
- Ask for the finish list in writing: everything between today and launch, with estimates. Use the list to find what is still uncertain and to compare progress with the working release.
- Get an outside read before you decide anything. Our Diagnostic is quiet and read-only, and you do not have to change teams to get one. Or take the 2-minute salvageability quiz to prepare your questions. The quiz is not a technical verdict.
Questions founders ask
How many warning signs prove a project is failing?
This guide does not give a number, because no tested cutoff exists. When a sign keeps repeating, look at the evidence behind it: scope changes, working demonstrations, access and the recovery plan.
What evidence should I ask the team to show?
Ask for the current release, a demonstration of the customer journeys you agreed on, the list of remaining work, the decisions that changed the scope and a named owner for each unresolved problem.
Are change orders always a bad sign?
No. New requirements and outside changes can create real extra work. Compare the request with the agreed scope and ask how its effect and its approval were written down.
What if the team cannot explain the technical issue clearly?
Ask what the issue does to the user, what the options and tradeoffs are, and what evidence you need to choose. If the decision is still unclear, an independent reviewer can help.
Tell us where it's stuck. We'll tell you what we'd do.
The consultation is free and takes 30 minutes. If a Diagnostic makes sense, it is $999, usually back in 24 to 48 hours, and it comes off your build if you go ahead.
Book a free consultation