To rescue an unfinished software project, work in this order: first secure access (code repository, servers, domain, app store accounts), then get an independent team to audit the code, and only then decide whether to continue or rewrite based on what the audit finds. The most common mistake is to start by asking a new agency for a quote to “just finish the rest”. Until someone has actually looked at the code, any price is a guess. This article walks through the steps we follow ourselves when we take over a project.
Why do software projects get abandoned?
In the projects we inherit, the cause is rarely a single act of bad faith. Usually several problems pile up: the scope was never written down, so the work keeps growing; a fixed price cannot absorb that growth, and the developer slowly drifts away from a project that is losing them money. When only one person understands the system, that person moving on to another job is enough. Sometimes the technical foundation is so weak that every new feature breaks two old ones and the team simply stops making progress. Knowing the cause matters, because it is how you avoid walking into the same trap with the next team.
What should you secure in the first 48 hours?
If the relationship has not completely broken down, get the following into your own name before any technical debate. If things are tense, send it as a single written request in list form:
- Source code repository: owner access on GitHub, GitLab or Bitbucket. A zip file is not enough; the commit history shows how the code evolved.
- Servers and cloud accounts: hosting panel, cloud provider, database and backups. Check whose card the bills are charged to.
- Domain and DNS: the registrar account should be in your name.
- Store accounts: App Store Connect and Google Play Console. If the app sits in the developer’s own account, plan the transfer as a separate step.
- Third party services: keys for payments, SMS, email, maps and push notifications.
- Environment variables, setup notes and any design files.
If you hold the code but someone else holds the server, the domain and the store account, you do not own the product. You own a copy of it.
Once you have access, rotate every password and API key. This is not an accusation, it is a standard handover step. If your contract assigns the source code and the economic rights to you, the request goes far more smoothly; we explain why those clauses belong in the contract from day one in our article on the software development contract. This is not legal advice; if there is a dispute, talk to a lawyer.
How does a code audit work?
A code audit means the new team actually runs the project and looks inside it. An opinion based on a demo or screenshots is not an audit. A good audit answers these questions in writing:
- Can the project be set up and run on a clean machine by following the documentation?
- Which features genuinely work, and which only exist on screen?
- Are the libraries and framework versions current, or are there components that are out of support?
- Does the database structure make sense, is there real data in production, and how will it be protected?
- Are there obvious security holes: hard-coded passwords, unprotected API endpoints, screens without permission checks?
- Is there any testing, error logging or automated deployment in place?
The output of the audit is a plain classification for each module, such as “solid”, “fixable” or “needs a rewrite”. That classification is effectively a map of the project’s technical debt, and it is the only sound basis for the next decision. How long it takes depends on the size of the project; what matters is that the audit is priced as a separate, bounded piece of work. That way you learn where you stand without committing to the follow-up job.
Continue or rewrite?
Every new team’s instinct is to rewrite, because reading someone else’s code is harder than writing your own. So make this call on the audit, not on gut feeling. As a rough rule: if the data model is sound and the problems are confined to individual modules, continuing with the existing code is almost always faster. If the data model is rotten, the core framework is on an unsupported version, or no change can be made without breaking something else, a rewrite is the lower risk option.
More often than not the right answer sits in between: keep what works, rewrite the most troublesome module first and improve the rest over time. If there are live users and data, migrating piece by piece is safer than switching everything overnight; the steps in our article on data migration from a legacy system apply here too.
How should the handover to a new team work?
Keep the first contract with the new team small: the audit plus the first critical fixes. You get to see how the team works, and you avoid tying everything to a single deal again. For the remaining work, ask for a written scope, acceptance criteria and payments split into milestones. Keep the repository in your own account from day one and let the new team contribute to it. We collected the questions to ask when choosing a vendor in our guide to choosing an enterprise software company.
To make sure the story does not repeat itself, build three habits along with the handover: a short setup document updated with every release, error monitoring and logging so problems are visible, and a team structure where at least two people know the project.
Conclusion
An unfinished software project is usually less of a write-off than it feels, but the order of rescue matters: access first, audit second, decision last. Do not discuss price before the audit, and do not accept a rewrite the audit has not justified. If you are sitting on a half-built project, our custom software team will review it first and give you a written assessment; after that you can request a quote if you wish.