Taking Over a Codebase From a Previous Developer
By CodexierPublished 5 min read
Sooner or later most software products change hands: a freelancer moves on, an agency relationship ends, or a co-founder leaves. The code is usually the easy part. What causes damage is everything around it: domains and cloud accounts in someone else's name, passwords nobody wrote down, a deployment only one person understood. This guide gives you the order to work in, whether you are the owner handing over or the developer taking over.
Access you must secure first
| Account | Why it matters | Check |
|---|---|---|
| Domain registrar and DNS | Controls whether the product is reachable at all | Registered to the company, renewal card valid |
| Code repository | The source of truth for the code | Company organisation owns it, not a personal account |
| Cloud hosting and database | Running system and customer data | Company billing, owner-level access for you |
| App Store and Google Play | Ability to publish app updates | Developer accounts in the company's name |
| Payment provider, email service, analytics | Money, customer communication, data | Admin access transferred, old users removed |
Accounts registered to a former developer personally can take weeks to transfer. Start this on day one.
Getting it running locally
The fastest way to learn a codebase is to make it run on a new machine. Every step that is not written down is a gap in the documentation, so note them all.
- Clone the repository and check which branch is actually deployed to production.
- Find the environment variables and secrets the app needs, and where they live today.
- Install dependencies with the versions in the lock file, not the latest ones.
- Set up a local or test database with realistic but anonymised data, never a copy of production personal data on a laptop.
- Run the tests, if there are any, and note which ones fail.
- Deploy a trivial change, such as a text change, through the normal release path to confirm it works end to end.
A quick risk audit
Before anyone builds new features, spend a few days finding out what could hurt you. The goal is a ranked list, not a rewrite.
| Area | Questions to answer |
|---|---|
| Security | Are secrets in the code? Is authentication home-built? Are admin routes protected? |
| Backups | Do backups exist, where, and has anyone tested a restore? |
| Dependencies | How outdated are the framework and libraries? Any with known vulnerabilities? |
| Data and GDPR | Where is personal data stored, and are there data processing agreements with vendors? |
| Costs | What does hosting and every service cost per month, and who pays? |
| Monitoring | Will anyone know if the system goes down or starts throwing errors? |
Documentation to create
- A one-page architecture overview: main parts, where they run and how they talk to each other.
- A setup guide that gets a new developer running locally in under a day.
- A release checklist: how to deploy, how to roll back, who is told.
- An account register: every service, its owner, billing and who has access.
- A risk list from the audit, with a suggested order of fixes.
Keep documentation in the repository next to the code, so it is versioned and moves with the project.
Red flags in week one
- Production changes made directly on the server, with code on the server that is not in the repository.
- No way to deploy without the previous developer's personal machine or credentials.
- Passwords or API keys committed in the code history.
- Customer data in places nobody listed, such as spreadsheets or a forgotten test database.
- Licences or contracts that say the code belongs to the previous supplier; check the IP clauses in your contract.
Decision rule: if the audit finds problems that can be fixed one by one, stabilise and improve the existing system. Consider a rebuild only if the core structure blocks every change you need; rebuild or refactor explains the trade-off. When not to buy from us: if the previous developer is still reachable and cooperative, a paid handover week with them is often the cheapest option. When they are not, our scaling and upgrade service starts with exactly this audit. Book a short call to talk through your situation.
Frequently asked questions
What if the previous developer will not hand over access?
Start with what the company owns: domain registrar, payment provider and app store accounts in the company's name can usually be recovered through the provider's support with proof of ownership. Your contract decides who owns the code; get legal advice if it is disputed.
How long does a takeover usually take?
Securing access and getting the system running typically takes days to a couple of weeks, depending on how much was documented. The risk audit adds a few days. New features should wait until both are done.
Should we rewrite the code when we take it over?
Rarely as a first step. A rewrite throws away working behaviour and takes months. Stabilise, audit and fix the worst risks first, then decide with real knowledge of the system.
Do we need the previous developer's help at all?
It helps a lot. A few paid hours of walkthrough, recorded if possible, can save days of guesswork. Ask for it as part of ending the engagement.
Inheriting a system you did not build?
In a free 15-minute call we go through what you have access to, what worries you and what a takeover audit would cover. You leave knowing the first three things to secure.
Book a free 15-minute call