It happens more often than it should: the freelancer stops answering the phone, the company that built the app closes down, or the employee who knew everything leaves. The website or app works, for now. But nobody knows how it’s built, where it runs or what happens if you touch it.

The good news: almost any abandoned project can be taken over. What matters is doing the steps in the right order, and the first one has nothing to do with code.

Step one: regain access

Before any change, find out what you have and who controls each piece. Often the accounts are in the developer’s name, and that becomes the main problem.

What What you check Why it matters
The domain which registrar, whose name, when it expires if it expires, the website and email disappear
Hosting, the server who has access, who pays without access, you can’t do anything
The source code where it is (a Git repository, an archive, only on the server) without the code, any change becomes a rebuild
The database where it is, whether backups exist the data is often the most valuable thing
Admin accounts who has them, whether you can reset passwords so you can work, not just look
External services payments, email, maps, SMS, invoicing: accounts and access keys an expired key can stop payments or emails
DNS and the SSL certificate who manages them, when they renew an expired certificate scares customers away
App store accounts whose name the App Store and Google Play apps are in without them, you can’t publish updates

Don’t let the domain expire

Of all of these, the domain is the most urgent. If it expires and isn’t renewed, someone else can register it. Find out as soon as possible whose name it’s in and when it expires.

How we assess the code

Once we have access, we do a technical assessment. Not to criticize someone else’s work, but to know what we’re standing on.

  1. We make a full copy. Code, database, uploaded files, configuration. Nothing changes before there is a copy we can go back to.
  2. We run the project in a separate environment. If we can run it on a server other than production, we understand what it needs to work and can test without risk.
  3. We check the versions. Many abandoned projects run on versions that no longer get security updates. For PHP, for example, the minimum version we consider safe today is 8.3; a project on an older version needs upgrading1.
  4. We check the dependencies. The libraries, plugins and themes used, with their known vulnerabilities.
  5. We read the code and the architecture. How clearly it’s organized, how much is hand-written and how much comes from a platform, where the fragile parts are, whether there are tests and documentation.
  6. We write a report. What we found, what the risks are, what’s urgent, what can wait and what each option costs.

Fix, refactor or rewrite?

The first temptation, after seeing messy code, is to throw it away and start over. It’s often a mistake. Joel Spolsky called rewriting from scratch “the single worst strategic mistake that any software company can make”, using the example of Netscape, which lost years rewriting its browser2. Old code, however ugly, holds years of fixes and special cases nobody remembers anymore.

On the other hand, sometimes the foundation really can’t be saved: an abandoned technology, security that can’t be fixed or an architecture that can’t support what you need. We wrote about this in our article on vibe-coded apps too.

The situation What we usually recommend
The code is reasonable, just unmaintained fix: updates, security, backups, documentation
The code works but is hard to change refactor: reorganize it piece by piece, without changing what it does
The technology is outdated or the foundation is wrong replace gradually: new parts are built alongside, old ones removed one by one
The project is small or barely works rewrite: cheaper than fixing

The option in the second-to-last row has a name: Martin Fowler calls it the “strangler fig”, after the fig that grows around a tree and gradually replaces it3. The app keeps working the whole time, and the risk is split into small steps.

What comes after the takeover

  1. We stabilize. Automatic backups, security updates, monitoring. The project is no longer at risk.
  2. We document. How to install it, how to publish a new version, where the accounts and keys are. So you no longer depend on one person’s memory.
  3. We keep developing. Only now do we add new features, on a foundation we understand.

How to protect yourself next time

  • the domain, hosting and external service accounts in your company’s name;
  • access to the code repository, not just to the server;
  • technical documentation handed over with the project;
  • a contract that clearly states who owns the code and the data.

Have a project left without a developer? We start with the assessment, so you know exactly what you have, what the risks are and what options exist, before you decide anything.

Request a project assessment

  1. PHP, Supported Versions. ↩

  2. Joel Spolsky, Things You Should Never Do, Part I, 2000. ↩

  3. Martin Fowler, Strangler Fig Application. ↩

Cover image: I Am Svoboda, Wikimedia Commons (CC0)