Taking a project over from your previous developer without losing anything
The developer is gone but your website or CRM is still running. What to check first, whose name the accounts should be in, and why it starts with an audit.
Your website or CRM is running fine, but the person who built it is gone. They stopped replying, changed jobs or simply closed their studio. As long as nothing breaks, it’s easy not to think about it. Then the first bug or new feature request reveals that nobody really knows how it all fits together or where things are kept. Here’s what to check first when you take a project over from a previous developer.
Access comes first
Make a list of everything the project can’t run without: the domain, the hosting or server, the code repository, the database, the admin panel. Add the service accounts too: email, payments, analytics, app store accounts, the Telegram bot token.
For each item, find out whose name it’s in. A domain registered to the old developer’s personal account is more common than you’d hope. Everything is fine while they keep renewing it out of habit, until the year they forget. Move everything you can over to your company. If you have no access at all, it can usually be recovered through the domain registrar, the hosting provider and each service’s support team, though it takes time.
Then backups
Check that backups exist, where they’re stored and when the last one was made. Most importantly, check that the project can actually be restored from them. A backup nobody has ever tried to restore may turn out to be useless on exactly the day you need it.
The audit: what’s inside
Once access and backups are sorted, you can look at the project itself. In an audit we go through the code: how it’s structured, how outdated the libraries are, whether there are tests. We look at hosting and security, speed and stability, and who owns everything we find.
You get a list of findings ranked by priority and a plan of fixes with estimates. Anything that’s getting in the way of work right now or putting data at risk comes first, everything else after. Our audit starts at $400, and the report is yours to keep even if you go on with another team.
Rewrite or keep building
A new team almost always wants to rewrite the project from scratch. Your own code is easier to read than someone else’s, and it feels like it’ll be faster. Usually it isn’t. A rewrite puts development on hold for a long time, and it’s easy to repeat the old mistakes.
We only suggest a rewrite when maintaining the old code costs more than building it again, and we show you the numbers. Otherwise we add new features in small releases, test each one, and the project keeps running the whole time.
Who looks after it next
After the audit and the first fixes, the project needs someone keeping an eye on it. Our retainer includes a set number of development hours each month, monitoring, library updates and a report at the end of the month. Response times for outages are written into the contract. It starts at $350 a month.
Making the next handover easy
The simplest rule is that everything belonging to the project should be your company’s from day one: the repository, the domains, the server, the accounts. After launch, sign a handover document listing the code, access and documentation. Then changing developers becomes a routine task that takes a couple of days, and nobody has to track down the person who built it.
