What to do when a supplier abandons a software project
When a supplier or developer walks away from a software project before it's finished, someone has to work out what's there, what's left to do and whether the code is worth keeping.
By Lee Gunn
On one project, the lead developer went missing, taking all knowledge of the system with them. The product ran a set of mysterious daily data processing jobs. The code was hard to read, there were no architecture diagrams and no documentation, and the many stakeholders each held a fragment of the picture. To make things harder, there was an intertwined legacy system which needed to be identified and decommissioned. Nobody wanted to take ownership of it.
I decided to take it on. The early weeks went on talking to everyone who knew something, reading the code, going through the Azure infrastructure, and piecing the system together in diagrams until it was clear what had been completed, what was still to do, and which parts belonged to the legacy system so it could be switched off. The product launched.
The pattern is common. An outside supplier, or a lone developer, builds the product or a large part of it, then walks away before it’s finished. Sometimes the code is perfectly sound and simply incomplete. Sometimes it really is in a poor state. Either way the owner is left asking what’s actually there and what’s left to do.
Secure what’s owned first
Before anyone judges the code, it’s worth confirming the business has hold of it. When a supplier walks away, the things to check are fairly consistent.
- The complete source code, with its change history, in a repository the business controls
- The accounts the product runs on, registered in the business’s name. That includes hosting, the domain name, app store listings and any third-party services
- Passwords, keys and certificates, changed once the supplier no longer needs them
- Database backups, and proof that one can be restored
- Whatever documentation exists, and a handover conversation if the people are still reachable
The code is probably better than it looks
Nearly every developer who picks up someone else’s code thinks poorly of it at first. Joel Spolsky gave the reason in one line, ‘It’s harder to read code than to write it’. Unfamiliar code tends to look worse than it is.
Code that’s already written has solved problems the business has already paid to solve, and many of those solutions aren’t recorded anywhere else. Consistency matters too. New work should follow the conventions already in place, even where a newcomer would have chosen differently.
Some codebases really do cost more to repair than to replace. Nobody can tell which on a first look, which is why discovery comes before any decision.
What discovery looks for
Discovery is the work of finding out what’s actually there and whether it’s salvageable. A handful of practical checks cover most of it.
- How far along is it really? On an unfinished project, the UI can be well ahead of what works underneath them. The honest measure is how much of the agreed scope runs end to end with real data.
- Can it be built and released? A new developer should be able to take the source, build it, and release a small change. If nobody can, that’s the first thing to fix.
- Is the repository the source of truth? Fixes are sometimes made directly on the live server and never copied back. Where that’s happened, the live server has taken over as the source of truth, and the code in the repository can’t be trusted to match it.
- Is the data sound? The data is often worth more than the code. A well-structured database can outlive several versions of the software around it. Problems in the data are also far cheaper and less risky to fix before a system goes live than after, once customers depend on it.
- Are there obvious security gaps? Passwords stored in the code, missing access checks, and unfished authentication are the usual ones.
- How long does a small change take? If a simple change takes days and tends to break something else, the code has a real running cost. Untidiness that doesn’t slow anything down can often be left alone.
The result is usually a plan to finish on the code that exists, sometimes replacing the weakest parts along the way. Starting again is rare, and deserves the most evidence.
How I can help
Picking up an abandoned project is hard, and most people understandably shy away from it. There’s no one to ask, the knowledge is scattered, and whoever takes it on inherits every decision made so far. I’ve done it a number of times over the years. The help comes in two parts:
The first is working out what’s there, which is what my independent technology assessment does. For a part-built system the scope is usually narrower than for an established product, and it’s agreed at the start. The work starts with read-only access to the code and whatever else tells the real story, such as the issue tracker, hosting accounts and any documentation. Alongside that come conversations with the people who commissioned the project and anyone who worked on it, where they’re still reachable. Most of the analysis then happens independently, so the time asked of the business usually amounts to a few days.
The report is written in plain language and covers three things.
- A realistic picture of what’s been built
- The risks that matter
- What to do and in what order
The second part is finishing it. Where appropraite, I can go in, pick up the system and deliver it, in small changes that are reviewed and recorded as they go. The decisions and knowledge get written down, so the business ends up with a product it owns and understands.
Where AI helps
A huge gain is in the discovery phase, the early work of finding out what’s there. Agentic AI has changed the pace of it. Pointed at an unfamiliar codebase, it can map how the parts fit together, trace what a scheduled job actually does, separate live code from dead, and draft the architecture diagrams that were never written.
For now, the judgement stays with a person. The agents produce the map, and deciding what’s worth keeping, what’s missing and what the business needs still comes from reading the code and talking to the people involved. The same tools can then speed up finishing the project, whilst gaining knowledge of the system. How that works in practice is in Using AI on an existing codebase without handing over ownership.
For a business in this position, a short exploratory conversation is a sensible first step.
References
- ‘Things You Should Never Do, Part I’, Joel Spolsky