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 spending with the work you agreed and the evidence delivered. These questions help distinguish a scope change from a delivery problem.
1. The budget grows but the demo does not
Ask for a demonstration of the agreed changes in the current release, alongside the work billed. If the product has not moved, identify whether time went into discovery, a blocked dependency or rework. The explanation should connect spending to evidence you can review.
2. Every small request becomes a change order
A change order can be legitimate when requirements change. Ask whether the request was included in the agreed scope, what changed and how the estimate was approved. Repeated disputes about the same boundary suggest the scope or change process needs repair.
3. The estimate to finish never shrinks
Compare the remaining-work estimate against the same scope each time. New requirements can increase it; completed work should be traceable in a working release. Ask the team to explain additions, removals and unresolved assumptions instead of relying on a percentage.
4. Staffing and review responsibilities are unclear
Ask who implements the work, who reviews it and who is accountable for the release. A changed team is not automatically a problem, but repeated handovers without continuity or review can slow delivery. Compare the staffing arrangement with the agreement.
Delivery signs
Missed deadlines need context and a credible next plan.
A missed date needs an explanation. Repeated misses need a review of the plan, dependencies and evidence used to report progress.
5. Sprint commitments are missed again and again
Look at the pattern of commitments and the reasons for misses. Ask what changed in scope, capacity or dependencies and how the next plan accounts for it. A recovery plan needs observable milestones and an owner, not another unsupported date.
6. "Done" breaks the moment users touch it
Ask to test the agreed journey with realistic data and expected exceptions. A happy-path demo can hide missing validation, access rules or integration behavior. Record reproducible failures and check whether 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 unresolved decisions. The team should distinguish required work from optional ideas and identify what is still unknown. A vague percentage cannot tell you which action gets the product closer to release.
8. Updates arrive late, thin, or only when you chase
Agree a review cadence, a named contact and the evidence each update should include. If updates remain late or unclear, ask what is preventing them. Communication problems need a concrete correction alongside the technical work.
Control signs
Control questions start with who holds the keys.
Ownership, recovery and documentation determine how well the business can operate 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 durable owner. Record any transfer dependencies and check the actual account permissions rather than assuming a shared login is sufficient.
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 handover gaps. Record and resolve them while the current team is available.
11. Technical questions get answered with jargon instead of English
Ask for the affected user outcome, the options, tradeoffs and the evidence needed to choose. You should be able to understand why a recommendation matters without learning the whole codebase. Request a written decision note when the explanation remains unclear.
12. Concern is growing without a clear decision
Concern is a reason to investigate, not a failure diagnosis. Put the specific observations in writing, ask for the team’s response and compare it with working evidence. An independent assessment can help when the remaining uncertainty 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 identify uncertainty and compare progress with the working release.
- Get an outside read before you decide anything. Our Diagnostic is quiet, read-only, and does not require firing anyone, 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?
There is no validated cutoff in this guide. Investigate the evidence behind a repeated pattern, including 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 agreed customer journeys, the remaining-work list, decisions that changed scope and named owners for unresolved problems.
Are change orders always a bad sign?
No. New requirements and outside changes can create legitimate extra work. Compare the request against the agreed scope and ask how its impact and approval were documented.
What if the team cannot explain the technical issue clearly?
Ask for the affected user outcome, options, tradeoffs and the evidence needed to choose. An independent reviewer can help when the decision remains unclear.
Hire TDAT to build what your business needs.
Book a 30-minute project call about the software or workflow you need. We will discuss what TDAT should take off your hands and define the scope before implementation.
Hire TDAT"We didn't hire an agency. We gained a weapon."
Dalton Locke, TDAT partner and Founder/CEO, PONO.AI