Taking Over a Codebase From a Previous Developer: What to Expect and What It Costs

The developer who built your system has gone. You have done the urgent things, or you are about to. Now you are collecting quotes from people who could take it over, and the quotes make no sense side by side.

One person wants two weeks to "get familiar" and will not commit to anything after that. Another gives you a fixed price for everything before seeing a single file. A third suggests starting again from scratch.

They cannot all be right, and you are not in a position to judge the code. You can judge the shape of the work, though, and that is what this post is about: what a takeover actually involves, what the first month looks like, what makes it expensive, and what a sensible proposal looks like.

A takeover has three phases, not one

Most of the confusion in quotes comes from people pricing different phases as if they were the whole job.

1. Assessment. Someone gets access, gets the system running somewhere other than your live environment, reads enough of it to understand how it fits together, and writes down what they found. This is days of work, not weeks. The output is a written report: what the system does, what is fragile, what is risky, and what they would do first.

That report belongs to you. If you decide not to hire the person who wrote it, you hand it to the next one, and they start a week ahead.

2. Stabilization. Before anyone adds features, the things that are quietly broken get fixed. Backups that may not restore. A deploy process that only existed on the previous developer's laptop. Passwords and keys that the previous developer still has. Accounts in someone else's name. The three problems your staff complain about every week.

From the outside, this phase looks like very little is happening. That is normal. It is the part that makes everything after it predictable.

3. Normal work. New features and changes, at a pace you can now plan around.

A proposal that skips straight to phase three is either very confident or has not looked yet. Usually the second.

What the first month actually looks like

It is slower than you hope. Three things make it so.

The first change takes far longer than the tenth. The first time anyone deploys a change, they find out how deploying works on this system. Sometimes that takes an hour. Sometimes it takes days, because the process was never written down and depends on something nobody remembers setting up.

There will be surprises. An outside service nobody listed. A job that runs at 2am and emails a report to someone who left two years ago. A price or tax rate typed directly into the code. None of these are disasters. They are the normal contents of a system that one person built and nobody else documented.

Your staff will be asked questions. A good person taking over will spend time with the people who use the system, not just with the code. Your system contains years of business rules that were never written down: the exception for one large client, the rounding rule your accountant asked for, the extra approval step added after something went wrong. The code tells them what happens. Only your staff can tell them why, and the why decides what is safe to change.

By the end of the month you should have a written list of risks, in order, and a deploy process that someone other than the previous developer can run. If you have neither, ask why.

What drives the cost

I am not going to put a single number on a takeover, because the honest range is enormous. Instead, here is what moves it, roughly in order of how much.

Whether the system can be run outside production at all. If nobody can start a copy of it on another machine, every change is made directly on the live system, carefully and slowly. Getting a working copy is often the single most valuable thing in the first two weeks.

Whether you control the accounts. Code hosting, servers, domain, app store accounts, payment and email providers. If any of these are in the previous developer's personal name, getting them back can take longer than any code change, and nothing else is safe until it is done.

How many outside services the system depends on. Each one is an account to recover, a key to replace, and a bill to check.

Whether anything is written down. Documentation and automated tests are rare in small company systems, and that is fine. But each one that exists saves real time.

Whether something is on fire right now. A stable system can be taken over carefully. A system that is failing every week has to be fixed while it is being learned, which costs more and carries more risk.

Two pricing patterns are worth knowing. The assessment can and should be a fixed price, because its scope is clear: look, run it, write it down. Stabilization is usually better as a fixed block of time with a written list of goals, because nobody knows exactly what is inside yet. Someone who offers a fixed price for the entire takeover before the assessment is either padding the price heavily or will be back asking for more.

Three proposals to be careful with

"We should rebuild it." Sometimes true, rarely in the first conversation. A rebuild throws away every unwritten business rule along with the code, and it is estimated from the visible features rather than the invisible rules. I wrote about why this instinct is so common in If Your Only Developer Quit Tomorrow.

A fixed price for everything, before anyone has seen the code. Nobody knows what is in there yet. The price is a guess, and you will pay for the guess one way or another.

"Give us two weeks to get familiar." Familiarity is fine. Two weeks with nothing written at the end is not. Ask what you will have in your hands when the two weeks are over.

What a sensible proposal looks like

It starts with a fixed-scope assessment that ends in a written report you keep.
It lists the access it needs, and asks for it in your company's accounts, not the contractor's.
It separates stabilization from new features, with a time limit and a list of goals.
It says what the person will not change in the first month.
It includes time with your staff, not just with the code.

None of this requires technical knowledge to check. It is a description of how the work is organized, and how someone organizes the work tells you most of what you need to know about how they will do it.

What you can do before anyone starts

You can make any takeover cheaper with an afternoon of preparation:

Run the four checks from If Your Only Developer Quit Tomorrow, starting with whether a backup actually restores.
Make a list of every account the system uses, whose name it is in, and whose card pays for it. Move anything in the previous developer's name into the company's name.
Write one page on what the system is for: who uses it, for what, on which days, and which parts would hurt most if they stopped working on a Monday morning.

That page is worth more to the next developer than most documentation, and it costs you an hour.

The short version

Taking over someone else's system is less about coding skill than about patience and writing things down. The best early sign that you have hired the right person is that they ask your staff questions before they change any code, and that at the end of the first month you have more written down than you did at the start.

If you are about to hand your system to someone new, a fixed-scope assessment with a written report is usually where I start - book a 30-minute call and I will tell you honestly whether you need me.