What should you secure this week?
While your developer or vendor can still be reached, you have the best chance of getting everything in order. Don't put it off. Make sure you have access to everything your software needs to run and to be changed:
- The source code: in a repository in your name, or at least a complete, recent copy. Ask for the history of changes too, not just the latest version.
- The hosting: the servers or cloud account your software runs on, with administrator rights for you.
- Your domain name: which registrar is it with, and in whose name? A domain that expires takes your website and your email with it.
- Accounts with external services: email services, payment providers, mapping services, app stores, anything your software talks to.
- Passwords and keys: database passwords, API keys and certificates. Have them handed over securely, not in an ordinary email.
Make a list and tick off what you actually have in hand. What you cannot open, you don't have.
If the previous party can no longer be reached, not everything is lost. If your hosting and your domain are in your company's name, you can usually get access back through the provider itself. If they are in your developer's name, it gets harder, and acting quickly matters all the more. Start with what you can open yourself, and note what is missing.
What do you actually own?
Access is one thing, ownership another. Check what your contracts say, and ask about anything unclear.
- The code: do you hold the rights to the software built for you, or do you use a licence on the supplier's software? That makes a big difference to what you are allowed to do with it.
- Licences: which external software, components or services does your application use, and in whose name are those licences?
- Contracts: what was agreed about termination, handing over the code and the documentation? Sometimes your contract says more than you think.
If something is unclear, settle it now, while you can still talk to the previous party. A few emails today save you a lot of argument later.
What are the risks of waiting?
Software without an owner often keeps working for months. That is exactly why many businesses put the question off. Meanwhile the risks grow:
- Security updates are left undone, while new vulnerabilities become known in the libraries it uses.
- A certificate, domain or subscription expires, and nobody notices until your software can't be reached.
- Backups stop running, or nobody knows how to restore them.
- Knowledge disappears: the longer you wait, the harder it gets to ask questions of whoever knows the software.
- A small change your business needs becomes a big problem because nobody dares to touch the code.
The worst moment to look for a new partner is when your software is already down. If you act now, you can plan the handover calmly instead of having to decide under pressure.
How does a takeover work?
A takeover doesn't have to be a leap in the dark. With us it follows set steps, as our page on taking over existing software explains. You know what you have before you decide.
- A free code audit, without obligation: we go through your code, servers and data and discuss what we found. You get a picture of the state of the code, the risks, our advice to keep building, modernise or rebuild, and a price for the takeover and maintenance.
- Documentation: we write down how your software works, from the architecture and setup to the integrations and the key processes. That way you are no longer dependent on one person.
- The handover: we put the code, the servers and all access in your name and take over management, planned so your users notice as little as possible.
- A maintenance plan: after that you choose the level that suits you, Maintenance, Support or Partner, cancellable monthly. Your software has a partner again.
Even if there is little documentation or the technology is outdated, you can move forward. The audit shows what is needed, and sometimes modernising step by step is better than rebuilding everything.
How do you prevent this next time?
You can't always prevent a developer from leaving. You can make sure it doesn't become a crisis. Three agreements make the difference:
- The code lives in a repository in your name. Your supplier works in it, but you own it and can always give others access.
- There is documentation that is kept up to date: how the software works, how to set it up and which integrations exist. Not just in someone's head.
- Your contract covers the end of the relationship: who owns the code, what you get when you stop and what notice period applies.
With us that is the standard: the code is yours, and if you stop later, you take everything with you. What else is worth putting in a maintenance contract is explained in our article on maintenance contracts.
Your first step: a free code audit
You don't need to have everything sorted before you get in touch. Bring what you have: access, contracts, an idea of what the software does. Book a free code audit. We look at what is there together, without obligation, and you only decide afterwards whether to continue.