A stalled software project is rarely missing another feature. It is usually missing a shared picture of what is done, who decides, and what “working” means. Use these questions before you hire the next person, and before you fund another round of the same work.
The aim is not a courtroom document. It is a diagnosis you can take into a conversation. If you already know the business outcome and only need the path, start with the Technology Decision Guide instead.
A stalled project is a diagnosis problem
Founders often describe the pain as “the developer disappeared,” “nothing ships,” or “we have spent too much.” Those are symptoms. The useful split is: can you still open the system, do you know what is live, can you name the stall, and would anyone agree that next month is a success?
Four areas to check
Work through them in this order. Skipping ahead to features is how a rescue becomes a rebuild you did not choose.
Ownership
If the current provider stopped tomorrow, what would you still be able to open? That is the test. Everything else in this checklist assumes you can reach the system.
- Who can approve a change in scope, and who can say no?
- Who has the accounts, the repository, the hosting, and the domain?
- Are those in a company inbox, or in a personal account you cannot recover?
- Who holds the payment methods that keep hosting and apps alive?
Write names, not roles. “The agency” is not an owner. A person with a login is.
What actually exists
Decks, prototypes, and “almost done” are not production. Separate them on paper so you stop arguing about imaginary software.
- What is live, what is in staging, and what exists only in a deck?
- Which parts do customers touch, and which parts are internal?
- What was the last change that reached production, and when?
- Which third-party tools does the live system depend on?
If nobody can point to a last production change, you do not have a delivery problem. You have a release problem, or you do not have a product yet.
Where the work stalls
Treat this as a diagnosis, not a blame exercise. The next partner needs the true bottleneck or they will staff the wrong skill.
- Is the delay in decisions, in access, in quality, or in an unclear brief?
- Which bugs are old, and which appeared after the last release?
- What are people doing by hand because the software cannot be trusted?
- What does the team argue about every week that never makes it into a ticket?
The definition of done
“Finish the project” is not a definition. A month the business can recognize is.
- What would a successful next month look like in the business, not in tickets?
- Which items are required for that month, and which are wishes?
- How will you know a fix worked, a week after it ships?
- What will you stop doing if that month works?
Work the sequence
Five steps. The first four do not require new features. They require attention. The fifth is where money for implementation belongs.
Before a new partner starts
Gather access, a list of what is live, and the outcome for the next month. Ask for a paid assessment before a large build. Bring the notes from this page. You will spend less time explaining the fog, and more time deciding what is worth keeping.
If the honest path is not a rescue but a different kind of system, go back to the four paths. Some stalled builds should not be finished. They should be replaced by a platform, or reduced to the one workflow that was always the point. If that platform choice is a store versus a content site, use Shopify vs WordPress.
What this checklist will not do
It will not tell you the project was a bargain. It will not invent a percentage for time saved. It will not name a vendor as the villain. It will tell you whether you can open the work, what is actually running, why it stopped, and what a good next month would be. That is enough to have a serious conversation, including a discovery call if you want a second opinion.
