Somewhere right now, a business owner is looking at fourteen months of invoices for a software project that was supposed to take six — and cannot log into anything the money bought. Project rescue is the unglamorous discipline of taking a development effort that has stalled, gone silent, or gone sideways, and getting to a working system without burning what has already been spent. It is more common than the industry admits: the developer who vanished, the agency that keeps presenting slides, the internal project that ate three deadlines.
The good news: a stalled project is rarely a total loss, and the recovery has a repeatable shape. The bad news: the instinct most people follow — pay a bit more, wait a bit longer — is precisely backwards. Here is the sequence that works.
Recognize it early: the six signs
Individually, each sign has an innocent explanation — that is what makes them dangerous. Together, they form a pattern: the demo keeps slipping ("next sprint" for the third month); spend rises while visible progress doesn't; the senior people who started the project quietly rotate onto other clients; you have never had access to your own repository; status arrives as presentations rather than software you can log into; and replies stretch from hours to days. The single most reliable test costs one sentence: "Can I click on what exists today?" A healthy project answers with a link. A failing one answers with a meeting.
The rescue sequence
1. Secure what you own — first, and politely. Before any difficult conversation, get the code into a repository you control, and confirm you hold the domains, hosting, databases, app store accounts, and API keys. Do it while relations are workable; the hardest rescues are the ones where the falling-out happened first and the vendor holds everything. If the contract says you own the work product — most do — exercising that clause is not hostile, it is hygiene.
2. Freeze new spending. Not as punishment — as diagnosis. Money flowing hides the true state of a project. Pause new work, pay what is legitimately owed, and make the next payment conditional on the audit.
3. Audit what actually exists. Have someone independent — not the original team — spend days, not weeks, answering three questions: does it run, what fraction of the promised scope genuinely works end to end, and is the codebase salvageable or a write-off? The result is usually neither of the extremes the parties claim: less than the vendor's "90% done," more than the frustrated owner's "nothing works."
4. Decide: salvage, restart, or walk away. Salvage when the audit finds a sound core with unfinished edges. Restart when the foundation itself is the problem — and here the sunk-cost reflex must die: code that cannot be safely built upon is not an asset, whatever it cost. What was not wasted in a restart is the requirements knowledge: fourteen months of a failing project usually produce an exceptionally clear picture of what the software actually needs to do. Walking away entirely is right when the business need itself has moved on.
5. Restart small — and demand a running slice. Whoever continues the work — the same vendor on new terms, a new team, or an AI-agent platform — give them the smallest meaningful slice and judge them on working software inside two weeks. This is where the ground has shifted: on Evonx, the restart is to describe what the system needs to do and see a running application within minutes — which converts the rescue's scariest question ("are we about to burn another year?") into something you can answer by clicking. The same applies when the stalled project was a rebuild of an older system; that path continues through legacy application modernization with the old system's behavior as the specification.
Not repeating it
Every rescued project should change how the next one is bought. Three contract lines do most of the work: you hold the repository from day one (the vendor works in your accounts, not the reverse); progress is demonstrated as running software on a fixed cadence — every two weeks, clickable, no slide substitutes; and payments map to working slices, not calendar months. Any competent vendor accepts these terms without friction; hesitation about them is the earliest warning sign you will ever get. The pattern behind all three is the one this entire discipline reduces to: working software is the only honest status report. Projects run that way rarely need rescuing — which is, in the end, the cheapest rescue of all.