How to rescue an unfinished software project
An unfinished software project can usually be rescued. The first step is to collect access to the code repository, servers, domain and third-party accounts in your own name. Then the code is reviewed, a written status report is produced, and you decide whether to continue, partly rewrite or start again.
Can an unfinished software project be rescued?
Yes. An unfinished software project can usually be rescued, and it rarely has to be rewritten from scratch. The developer may have left, the agency may have closed, or the work may simply have stalled. Whatever the reason, if part of it works, saving that part is usually possible.
First, though, you need to know what you have. This post lays out the order we follow when we take over a project. You can use the same list if someone else is going to carry the work on.
What should happen in the first week?
In the first week, nobody writes code. You collect access. You need the keys to every place the project runs. Otherwise, even with a new team ready, you can lose months waiting for one account password.
Go through the list below item by item. For each one, ask two questions. Whose name is this account in? Who can change the password and permissions?
Access checklist
- 01 Code repository The repository on GitHub, GitLab or Bitbucket should sit in your account or your organisation, with every branch and the full history. A zip file of the code is not enough.
- 02 Servers and cloud account The servers and cloud account the application runs on, and their billing, should be in your name. You should hold administrator access.
- 03 Domain and DNS The domain should be registered to you. You need access to the registrar account and the DNS settings.
- 04 Database and backups You should know the database credentials and where the latest backup lives. A restore from backup should be tested at least once.
- 05 Third-party services Payment provider, email and SMS services, map and push notification keys, invoicing integrators. List every account and key.
- 06 App store accounts If there is a mobile app, the App Store and Google Play accounts should be in your name. Collect the app signing keys as well.
- 07 Configuration and documents Collect configuration files, setup notes, any technical documentation and the list of open tasks.
We explain why the domain and hosting must be in your name in who should own your domain. Moving a domain to another registrar usually needs a transfer code. For generic domains, ICANN sets those rules. Country-code domains, such as .tr, follow their own process, so ask your registrar.
What does a code review look at?
A code review shows the project's real state today: what works, what does not and what is risky. It is based on what runs, not on what anyone says. During a review, we look at:
- Does it run: can the project be installed from scratch on a fresh machine and started?
- Is it current: are the language, framework and library versions still supported?
- Is it safe: are passwords and keys written into the code? Are there known vulnerabilities?
- Are there tests: are there automated tests, and do they pass?
- Is the data sound: does the database structure make sense, and is the data consistent?
- Is it readable: can another developer read the code and carry on?
Problems that pile up in these areas and cost more to fix the longer they wait are called technical debt. The review ends with a written status report. It says, in plain language, what is solid, what needs fixing and what needs rewriting. You should be able to read it and decide without a technical background.
Should you continue or start over?
Decide by whether fixing the existing code is less work than rewriting it. In most projects the answer sits in between. The solid parts stay, the problem parts are rewritten.
A full rewrite comes up when the technology is no longer supported, when the data structure contradicts the business itself, or when security problems have spread through the whole codebase. Even then, the data and the design can usually be saved.
Be careful if a new team's first reaction is always "let's rewrite it". Sometimes that is right. Sometimes it is the easy way to avoid reading the code. Ask for the reasoning in writing, in the report.
| Situation | Usual decision | What is usually kept |
|---|---|---|
| Code runs, stack is supported, some features missing | Continue | Almost everything |
| Core is solid, some modules are fragile or insecure | Partial rewrite | Data, design, solid modules |
| Stack is unsupported or data model contradicts the business | Start over | Data and design |
| Code cannot be obtained at all | Start over | Whatever the live system and database reveal |
How do you protect the live system during the handover?
Back it up and build a separate test environment before changing anything. If the project is live and your customers use it, the first goal is to break nothing. A full backup of the database and files comes first. Then a copy of the project is brought up in a staging environment, a copy of the live system where changes can be tried safely.
Fixes are tried there first, then released. Every release must be reversible. If something goes wrong, the system returns to its previous state within minutes.
How should you talk to the previous developer?
Calm, written communication gets the fastest results. Instead of blaming, send a list of what you need: access, documents and open tasks. A short handover call can explain more than weeks of reading code.
If they cannot be reached, the work does not stop. If the accounts are in your name, the new team moves forward by reading the code. If they are in someone else's name, you need to get them back first. That is why the access list is step one. Registrars, cloud providers and app stores can usually help you recover an account if you can prove you own the business behind it.
How do you avoid this happening again?
Keep everything in your own name from day one, and define in writing when the work is finished. If the repository, servers, domain and accounts belong to you, no team becomes irreplaceable. A code repository is where the code lives together with its full history.
We write a new definition of done for every project we take over. What counts as finished, by which date and how it will be checked is signed on day one. In an unfinished project, someone has usually heard "90 percent done" before. With us it is done or not done. The full approach is on our project takeover page. Once the project is back on its feet, maintenance and support keeps it there.
Frequently asked questions
I only have a copy of the code. Is that enough?
It is enough to start, but a repository with its history and branches is worth far more. Ask the previous developer for the repository with its full history.
How long does a code review take?
It depends on the size of the project. Small projects take a few days, larger ones longer. We give you the timeline in writing once we have seen the access.
I cannot reach the previous developer. What should I do?
First check which accounts are in your name. Registrars, cloud providers and app stores will usually help you regain access if you can prove you are the account owner.
Do you take over projects built with other technologies?
If they are close to the technologies we use, yes. If not, we say so plainly and, where we can, suggest a better route for you.
My developer abandoned the project. What should I do first?
List who owns the repository, servers, domain and third-party accounts, and move them into your name. Then ask the previous developer, in writing, for the repository, documents and the list of open tasks. The code review and the continue-or-rewrite decision come after that.
Is taking over cheaper than starting again?
Often yes, because the solid parts are kept and only the problem parts are rewritten. If the stack is unsupported or the data model fights the business, a rewrite can be less work. Which one is cheaper can only be said after the code review, with the reasons in writing.
Will my site or app go offline during the takeover?
It does not need to. We take a full backup, bring the project up in a staging environment and try fixes there. Every release is reversible, so your users should not notice the handover.
Who owns the status report?
You do. The report is written for you and describes the project in plain language. You can use it whichever team finishes the work.
Sources
- 01 Transfer Policy · ICANN