The developer has stopped answering. Maybe they moved on, maybe the relationship ended badly, maybe they simply went quiet. The software still runs, which is the part that makes people wait longer than they should - it works, so it is not yet an emergency.
It is an emergency. Every week you wait, something expires that you did not know was in someone else's name.
Check these five things today
Not next week. Each of these can be recovered while the account is alive and becomes an expensive legal problem once it lapses.
- The domain registrar. Look up your domain on a WHOIS service. If the registrant is not you or your company, you do not control your own address. This is the one that ends businesses.
- The DNS. Often at a different provider from the registrar. Whoever controls DNS controls where your mail goes.
- The server or hosting account. Whose card is it billed to? An expired card on someone else's account deletes your site with an automated email nobody reads.
- The code repository. GitHub, GitLab, Bitbucket. If you have never seen it, assume you do not have it.
- The third-party accounts. The payment processor, the invoicing service, the SMS gateway, the analytics. Each is a separate login and each can be cancelled without you.
Write down what you find. That list is the actual state of your ownership, and it is usually worse than the contract suggests.
"We own the code" is not the same as owning the system
Most contracts assign copyright in the source code, and most clients read that as ownership. It is a smaller thing than it sounds.
Owning the code means you may legally use and change it. It does not mean you have a copy of it, that anyone can run it, that the accounts it talks to are yours, or that the person who knows why it was built that way is obliged to explain. I have taken over systems where the client held perfectly valid copyright over software they could not deploy, on a server they could not access, using API keys registered to a personal email address at a company that no longer existed.
Ownership is a checklist, not a clause.
What is usually salvageable
More than people fear. The code being unfamiliar is not the same as the code being bad, and inherited software has a reputation it does not always deserve - a system somebody else wrote will always look worse than one you wrote, because you cannot see the reasoning.
What genuinely decides it is narrower than the code quality:
- Is the data intact and exportable? This is the only irreplaceable part. Code can be rewritten in weeks; five years of customer records cannot be reconstructed at all.
- Does it still deploy? A system nobody can rebuild from source is a system running on a machine you must never reboot.
- Are the dependencies still supported? A framework three major versions behind is a budget, not a blocker.
- Are the secrets recoverable? Keys can be reissued. The accounts that hold them are the problem.
Notice that none of these is "is the code elegant". I have stabilised genuinely ugly systems in a week because the data was clean and the deploy worked, and recommended replacing tidy ones where neither was true.
The honest answer is often "less than you think"
People arrive expecting to hear that everything must be rebuilt, partly because that is what they have been told by whoever quoted last. Sometimes it is true. More often the system is sound and what failed was everything around it: nobody could deploy, the backups were never tested, and one person held all the accounts.
That is a week of work and a handover, not a rewrite. I would rather tell you that and take a week of work than sell you six months you did not need - partly because it is true, and partly because the client who was told the truth is the one who comes back.
How to not be here again
Whoever you hire next, insist on this before the first line is written, not at the end: every account is created in your name, by you, and the developer is added to it. Not transferred at handover. Created yours from the beginning.
It costs nothing, it takes an afternoon, and it is the entire difference between a supplier change and a crisis. If a developer resists it, you have learned something valuable early, while it is still cheap to learn.
The rest of the handover standard - documentation, tests, a deploy your own team can run - is on my services page, and the reason I care about it this much is in the note about who actually uses your software.