What It Costs to Take Over Someone Else's Codebase

Somebody sends over a repository link and asks what it would cost to pick it up. It is a completely reasonable question and it cannot be answered, in the same way a surveyor cannot price repairs from a photograph of a house.

What can be described is the shape of the number: what makes one takeover a fortnight and another one six months, and which of those things you can find out cheaply before committing.

Why it is quoted in two stages

Any firm that gives you a fixed price for a takeover before reading the code is pricing their risk, not your project, and they will price it high because they have to. You pay for the uncertainty either way.

The alternative is a short, bounded first stage: a few days of reading and testing that ends in findings and a plan. After that a fixed quote is possible, because the unknowns that would have been padded are now known. If the findings are bad enough, you also get the option of walking away having spent days rather than a quarter. What that stage covers is described in the code audit article.

What actually moves the number

In rough order of impact, and none of these is about whether the code is tidy.

1. Whether you control the accounts. Recovering a developer account or a domain from an unresponsive former contractor can take longer than the engineering, and no amount of money speeds it up.
2. Whether it builds from the repository alone. If it only runs on a machine nobody has, the first task is reconstructing an environment by deduction, which is slow and produces nothing visible.
3. Whether anything is tested. Without tests, every change needs manual re-checking of everything it might touch, and that tax is paid on every single piece of work afterwards.
4. Whether the data model fits what the business plans next. Application code can be changed quietly; a schema with live customer records in it cannot.
5. Whether anyone is left who knows why. One person available for a few hours of questions can remove weeks of archaeology.

Notice what is absent from that list. Framework choice, code style, and whether the previous developer's approach matches your new one are mostly aesthetic, and a firm that leads with them is telling you about their preferences rather than your risk.

The findings that change the price

Most discoveries add tasks. Three tend to change the plan instead.

The first is that one customer can reach another's data. That stops feature work until it is fixed, and the fix can be a day or a redesign depending on how the app was put together. The second is secrets already public, which is cheap to fix and expensive to ignore, because anything exposed has to be replaced everywhere it is used. The third is a dependency that no longer receives security updates, which turns an open-ended maintenance plan into a dated one.

None of these is a reason to abandon a project. All of them are reasons to know before you agree a timeline, which is the entire argument for looking first.

When finishing costs more than starting again

Sometimes a rewrite genuinely is cheaper, and it is worth being able to recognise the case rather than treating it as defeatism or as the default.

The honest signal is not ugliness. It is that small changes keep causing distant breakages, which means nobody can predict the cost of anything, which means every estimate afterwards is fiction. The other honest signal is a data model that blocks the business's next year, since that has to be rebuilt whether or not the code around it is.

Be suspicious of a rewrite proposed in the first week. Reading someone else's work is slow and unrewarding; starting fresh is neither, and that asymmetry biases every developer who has ever looked at inherited code.

How to make yours cheaper to take over

If you are reading this before the handover rather than after it, a few things cost nothing now and save a great deal later. Put every repository, domain and store listing under company accounts from the start. Make the final payment depend on somebody other than the author running the project from a clean machine. Ask for a short written description of how it deploys and what it depends on.

The pattern we see is consistent: projects whose previous developer expected a successor are dramatically cheaper to inherit, and it shows within the first day. None of those measures requires technical judgement from you, which is what makes them worth insisting on at the point you have the most leverage, before the contract is signed.