We do a certain amount of rescue work — projects that stalled at 60%, 70%, sometimes 90%, and need someone to finish or restart them. The pattern is remarkably consistent. In nearly every case the code was not the problem, and in nearly every case there was an identifiable moment, months earlier, where the failure became inevitable and nobody noticed. Here are the nine patterns, the early warning sign for each, and the specific check that catches it.
The short version
- Projects fail from unclear decisions, not weak engineers. Ambiguity compounds; bad code can be refactored.
- The most reliable predictor of failure is no single named decision-maker on the client side.
- The second is no working software until late. If nothing is demonstrable by week four, you have no feedback loop.
- "90% done" for more than three weeks means the remaining 10% was never scoped.
- Every check below costs an hour or less. Every failure below costs weeks.
1. Nobody is actually the decision-maker
Four stakeholders each request changes; none can approve. The development team receives contradictory direction, implements the most recent instruction, and is blamed by whoever spoke first. Work gets built twice.
Warning sign: a decision from last week gets reopened by someone who was not in the meeting. Approval emails carry five people in CC and no signature.
The check: before kickoff, name one person who can say yes and one who can say no, in writing. Everyone else advises. If a decision needs a committee, schedule the committee — but the output must be one instruction from one person.
2. Requirements were a wish-list, not a specification
A brief that says "user management, reports, notifications" is three words describing three months of work. Both sides read the same sentence and picture different products. The gap surfaces at demo time, and by then the database is already shaped around the wrong assumption.
Warning sign: the estimate was produced in under an hour from a one-page brief. Nobody has asked you an uncomfortable question yet.
The check: for each major feature, write acceptance criteria — the specific conditions under which it is finished. Our requirements guide covers the format. If a studio quotes without asking about edge cases, roles or error states, they have quoted their guess, not your project.
3. No working software until late
Months of design documents, wireframes and status reports, and nothing anyone can click. Everyone feels productive. Then integration week arrives and the assumptions collide.
Warning sign: week six, and progress is measured in percentages rather than in features you have personally used.
The check: demand a deployed, clickable build by week three or four — ugly, incomplete, real. Then a new build every one to two weeks. Percentages are opinions; a build you can open is a fact. This single practice catches more problems than any other item on this list.
The question that cuts through status reports
"Can I use it today?" Not see a screenshot — use it. If the answer has been no for three consecutive weeks, something is wrong regardless of what the report says.
4. Scope grew without anything moving
Scope creep is not the villain; unpriced scope creep is. Every added feature is reasonable in isolation. Nobody adjusts the date, the budget or the priority list, so the team absorbs it by cutting testing and rushing the parts nobody is watching.
Warning sign: features are being added and the launch date has not moved. That is not efficiency; it is quality being spent silently.
The check: a written change log. Every addition records its cost in days and what it displaces. The answer to "can we add this?" should be "yes, and it moves launch by four days" or "yes, if we defer X" — never an unqualified yes.
5. The client side has no time
This one is uncomfortable and it is the most common failure we see. Software needs decisions, content, test data, feedback and access to the people who do the work today. If nobody on the client side has three to five hours a week, the project stalls waiting on you, and the studio's team gets reassigned.
Warning sign: questions take more than 48 hours to answer. Review meetings get rescheduled twice. Test data has not arrived.
The check: before starting, name the person who owns this internally and confirm the hours are actually free — not theoretically free. If they are not, either narrow the scope until it fits their availability or delay the start. Starting a project nobody has time for is the most expensive form of optimism.
6. Testing was treated as a phase, not a habit
Testing squeezed into the last week of a twelve-week project is not quality assurance; it is bug discovery with no time to fix anything. Worse, bugs found at the end are the expensive kind — the ones rooted in decisions made in week two.
Warning sign: "QA" is a single bar at the end of the Gantt chart. Nobody has mentioned test devices.
The check: testing runs alongside development from the first feature. Ask specifically: who tests, on which devices, and what happens to a bug once found? For mobile, insist on a mid-range Android device on a poor connection, not a simulator. And agree a bug triage scale up front so "critical" means the same thing to both sides.
7. Integrations were assumed to work
A payment gateway, a government portal, a courier API, a legacy accounting system. The estimate assumed the documentation was accurate, the sandbox existed and someone at the other organisation would answer email. Frequently none of those is true, and the delay is entirely outside the development team's control.
Warning sign: an integration is scheduled for week eight and nobody has yet obtained credentials or successfully made one test call.
The check: validate every third-party integration in the first two weeks with a throwaway script that makes one real call. Also name the person on the client side responsible for chasing that vendor — this is not a task a development team can do on your behalf.
8. No single technical owner
Three developers, three architectural opinions, no arbiter. The codebase gets two state management patterns, two API conventions and two folder structures. Each individual piece is defensible; the whole is unmaintainable, and onboarding the next developer takes a month.
Warning sign: you cannot name the person responsible for technical decisions. Different developers explain the same system differently.
The check: ask who owns the architecture, by name, and how much of their week is on your project. "The team decides collectively" is a warning, not a value — collective ownership works when someone is accountable for coherence.
9. Nobody planned for after launch
Launch day is a milestone, not an ending. Then a browser update breaks a form, a dependency reaches end of life, Apple raises its minimum SDK, and the team that built it has moved on with no documentation and no handover.
Warning sign: the contract ends at launch. There is no warranty period, no support arrangement, and no answer to "who do we call at 9pm during a sale?"
The check: agree the post-launch arrangement before signing — warranty period, response times, retainer cost. Confirm you hold the repository, the deployment credentials, the domain, the store accounts and the database backups, in your own organisation's name. Our hiring guide lists exactly what to ask for.
If you are already in trouble
Most rescue engagements arrive at the same three sentences: it is 80% done, the previous team is unresponsive, and the launch was supposed to be last month. What we do, in order:
- Stop building. Adding features to an unstable project makes the assessment harder and the outcome worse.
- Take inventory. What exists, what runs, what is deployed, what is in version control, who holds which credentials. This step alone frequently reveals that "80% done" meant "80% of the screens exist and none of them save data".
- Get one thing working end to end. One complete flow, deployed, usable. It re-establishes a factual baseline and restores everyone's judgement.
- Re-scope honestly to a minimum launchable product. Not the original spec — the smallest thing that delivers value and can ship in weeks.
- Then decide: finish or rebuild. Rebuild if the data model is fundamentally wrong, if there is no version control history, or if reading the existing code costs more than rewriting it. We have recommended both, and the honest answer is sometimes the expensive one.
"90% done" that has been 90% done for a month is not 90% done. It means the remaining work was never scoped — and unscoped work has no end date by definition.
The one-page pre-flight check
Print this. Ask it before any project starts, of yourself as much as of your development partner.
- Who is the single decision-maker? (a name)
- Do the top ten features have written acceptance criteria?
- When will I first click a deployed build? (a date, in the first month)
- How are change requests priced and logged?
- Who on my side owns this, and are their hours genuinely free?
- Who tests, on what devices, and how are bugs triaged?
- Has every third-party integration made one real test call?
- Who owns the architecture, by name?
- What are the warranty, support and handover terms — in writing, now?
Nine questions, under an hour. It will not guarantee success, but it eliminates the failure modes that account for most of the projects we are called in to save. If you are mid-project and something on this page felt uncomfortably familiar, tell us where you are — the first conversation costs nothing and we will give you a straight read on whether it is recoverable.