TL;DR: A stalled software project is rarely saved by hiring a faster team and pointing it at the old backlog. It is saved by stopping long enough to find out what actually exists: who controls the code, accounts and data, whether the software builds and runs, and which parts are worth keeping. Then you pick one of three paths: continue the current codebase, stabilize it and rebuild the worst parts, or start again and reuse what is reusable. The order matters. Secure access first, assess second, decide third, and only then commit to a new timeline, delivered in small increments that each produce working software you can see.
Most stalled projects look the same from the outside. The launch date has moved three times. The demo still shows the same screens it showed two months ago. Every status update mentions an unexpected blocker, and the budget is mostly spent. Sometimes the original vendor has gone quiet, sometimes the in-house developer who built it has left, and sometimes everyone is still working hard and nothing is getting finished.
If that is where you are, the instinct is to find someone new and tell them to finish it. That instinct is right about needing help and usually wrong about the first step. Here is how a recovery actually works, what to secure before you change anything, and how to decide whether the existing code is worth saving.
Signs a project is stalled, not just slow
Every software project has slow weeks. A stalled one has a pattern:
- Progress is reported, not shown. Updates describe work in progress rather than features you can click.
- The finish line keeps moving. Each estimate is confident, and each one slips.
- Fixing one thing breaks another. Bugs that were closed come back, and simple changes take weeks.
- Nobody can deploy it but one person. Releases depend on a specific laptop, account or individual.
- Questions get vague answers. "It's nearly done" without a list of what remains.
One or two of these on their own can be a rough patch. Three or more usually means the problem is structural, and more effort applied the same way will produce more of the same.
Step one: secure access before anything else
The most expensive recoveries are the ones where the buyer discovers, mid-dispute, that they do not control their own product. Before you change vendors, have a hard conversation or even announce a change, make sure you hold or can obtain:
- The source code, in a repository your company owns, with full history, not a zip file.
- Hosting and cloud accounts, with your company as the owner and billing contact.
- Domains and DNS, registered to you.
- App store accounts for any mobile app, under your organization.
- Third-party services: payment providers, email, analytics, AI model APIs, maps, anything with a key in the code.
- The production database and backups, with a recent backup you have confirmed can be restored.
- Credentials and secrets, rotated once the handover is complete so former contributors no longer have access.
We go through this list in more detail, including what your contract should say, in software ownership and handover. If the project is already stalled and none of this is in your name, getting it moved is the single highest-value thing you can do this week. Nothing else in a recovery is safe until it is done.
Step two: assess what actually exists
Once you have access, the next job is an honest inventory. Not a rewrite proposal and not a sales pitch, just answers to a short set of questions. A good assessment is a fixed, short piece of work, and it is the same exercise an investor commissions before funding a company, which we describe in technical due diligence.
Does it build and run?
Can someone who did not write the code get it running on a clean machine from the instructions in the repository? Can it be deployed to a test environment without the original developer? If the answer is no, that is the first fix, because every later step depends on it.
What works, and what only looks like it works?
Demos are often built on the happy path. The assessment should walk the main user journeys end to end, with realistic data, and note where the software breaks, where screens exist without the logic behind them, and where data is faked or hardcoded.
Where is the risk concentrated?
In most stalled projects the trouble is not spread evenly. It sits in a few places: an integration with an external system, a data model that does not fit the business, payments, permissions, or a real-time feature. Finding those few places tells you most of what you need to know. In software that handles money, such as an accounting platform like Fyuel, the ledger and reconciliation logic is where correctness matters most, and it is the first thing we would read in any inherited finance product. We cover why in building financial software.
Is there anything a test can protect?
Automated tests, even a few, tell you whether a change has broken something. Their absence does not condemn a codebase, but it means the first weeks of any recovery include building that safety net around the parts you plan to keep.
What does the team that built it know?
If the previous developers are reachable and the parting is civil, an hour or two of their time explaining the architecture, the shortcuts and the known problems is worth paying for. It is the cheapest documentation you will ever buy.
Step three: continue, stabilize or restart
With the assessment in hand, there are really only three options.
Continue the existing codebase
This is right when the code builds, the structure is reasonable and the stall was caused by something outside the code: unclear priorities, a team that was too small, a vendor that stopped responding. The new team learns the system, fixes the deployment, adds tests around the risky parts and starts shipping. It is the cheapest path, and it is chosen less often than it should be, because new teams tend to prefer their own code.
Stabilize, then replace the worst parts
This is the most common honest answer. Most of the system is usable, but one or two areas are causing most of the pain. You keep the product running, put tests around the boundaries, and rebuild the problem areas one at a time behind those boundaries. It is the same incremental approach we recommend for older systems in legacy system modernization, applied to software that happens to be young.
Restart, reusing what is reusable
Sometimes the foundation is wrong: the data model cannot represent the business, the technology choice cannot meet a core requirement, or there is so little working software that keeping it costs more than it saves. Restarting is legitimate in those cases, but it should rarely be a true blank page. Designs, research, requirements, test data, integrations that do work and lessons about what users actually need all carry over. A restart that throws those away repeats the original project's mistakes at full price.
A useful test: ask whoever recommends a rewrite to name the specific parts that cannot be fixed in place and why. If the answer is general ("the code quality is poor"), get a second opinion. If it is specific ("the schema stores one price per product and the business needs per-customer pricing across every module"), take it seriously.
How to restart delivery without repeating the stall
Whichever path you choose, the way the work is run afterwards matters as much as the technical decision.
Re-baseline the scope. The original specification was written before anyone learned anything. Rewrite it as a short list of outcomes a user must be able to achieve for the product to launch, and move everything else to after launch. The approach in writing a software project brief works just as well for a recovery as for a new build.
Ship something working early. The first milestone of a recovery should be small and visible: a fixed deployment pipeline, a broken journey that now works end to end, a release to a test group. It rebuilds trust on both sides and proves the new arrangement can deliver.
Make progress visible in software, not reports. Agree that every update includes something you can use in a test environment. If a week passes with nothing to show, that is a conversation, not a footnote.
Structure the contract for the uncertainty. Recoveries carry more unknowns than new builds, so a fixed-price assessment followed by milestone-based or capped delivery usually fits better than one large fixed bid. We compare the options in fixed price vs time and materials.
Keep the people who know the business close. A stalled project often lost its product owner along the way. Someone on your side needs the time and authority to make decisions weekly, or the new team will drift exactly as the old one did.
Where an AI-native team changes the maths
Recoveries used to be expensive mostly because reading someone else's code is slow. A senior team working with AI coding agents can now map an unfamiliar codebase, trace how data moves through it, and draft the missing tests far faster than reading it line by line. That does not replace engineering judgment about what to keep, but it shortens the assessment and makes the "stabilize and replace" path cheaper than it used to be, which means fewer projects need to be restarted from scratch. We describe how we work this way in our ship-in-days playbook.
It also makes the speed of routine work a poor guide to who should lead a recovery. The deciding factors are the same as ever: how carefully the team reads before it writes, whether it tells you which parts are good, and whether it can explain its recommendation in plain language.
The same principles, wherever the project stalled
The details change by type of product, but the order does not. A mobile app adds app store accounts and signing keys to the access list. An SDK that ships inside other companies' apps, like the cross-platform SDKs we built for Geonode, adds versioning and backward compatibility, because customers are already running the old version; we cover that in cross-platform SDK development. A product that started on a no-code platform often stalls at the platform's limits rather than through anyone's fault, which is its own decision covered in outgrowing no-code. And if the project is a VR or AR build, headset SDKs and engine versions join the inventory, as we explain in XR app maintenance.
Questions to ask a team before it takes over
- What will you need access to in the first week, and in whose name should it sit?
- How long is your assessment, what does it cost and what will we receive at the end?
- How will you decide between continuing, stabilizing and restarting?
- If you recommend replacing something, can you name the specific part and the reason?
- What will the first visible milestone be, and when?
- How will we see progress each week without relying on a written report?
- If we stop after any milestone, will we have everything needed to continue with someone else?
The bottom line
A stalled project feels like a delivery problem, so the natural response is more delivery. The better response is a short pause: take control of everything you own, find out honestly what exists, and choose deliberately between continuing, stabilizing and restarting. Most projects are more recoverable than they feel in the worst week, and almost all of them are cheaper to recover than to start again without understanding why they stalled.
Sitting on a project that has stopped moving? Book a demo and we will walk through what you have, what you need to secure first and the fastest honest path to a working release. See our work: Fyuel, LectureNotes AI, Raqts, Geonode, ARCortex and more.