Taking Over Someone Else's Codebase

The rewrite reflex is usually wrong

Every developer's first instinct on inheriting a codebase is that it is bad and should be rewritten. It is almost always the wrong call.

The existing system, whatever its faults, encodes years of business rules discovered the hard way. A rewrite discards all of that and rediscovers it, one production incident at a time.

“This code is terrible” usually means “I did not write this code”. The interesting question is whether it works and whether it can be changed safely.

Week one: audit

1. Can it be run locally? If not, that is the first job.
2. Is it in version control with real history?
3. Are there tests, and do they pass?
4. How out of date are the dependencies, and are any unsupported?
5. Where are the secrets, and have any been committed?
6. What is the deployment process, and is it written down?
7. Where does the business logic actually live?

This produces a written report with a severity on each finding. It is a fixed-price piece of work, usually five to eight days, and the report is yours regardless of what you do next.

Week two: stabilise before changing

Before any feature work, we make the system safe to change: get it deployable, add monitoring, ensure backups exist and restore, and put characterisation tests around the parts we will touch.

• A repeatable deployment, so releases stop being events
• Error tracking, so failures are reported rather than discovered
• Verified backups
• Tests around the areas about to change, describing current behaviour
• Dependency updates for anything with a known vulnerability

Characterisation tests deserve a note: they record what the system does now, not what it should do. That is exactly right when inheriting code, because current behaviour is what your business depends on.

The verdict

Only the last two rows lead to substantial rewriting, and even then we replace piece by piece behind a stable interface rather than starting again.

Rewriting piece by piece

Where replacement is genuinely needed, the safe method is to put the new implementation behind the same interface, run both, compare the outputs, and switch when they agree.

It is slower than a clean rewrite and it never has a moment where the business is betting on a big-bang cutover. Every large rewrite we have been asked to rescue was a big-bang that ran out of budget at 80%.

What it costs to take over

An audit is typically £3,000–£8,000 depending on size. Stabilisation is usually two to four weeks. After that, ordinary development at a normal pace — slightly slower for the first month while the team learns the system.

We do not charge a premium for inherited code, and we will tell you honestly if the honest answer is that another supplier already knows it better and should keep it.

Frequently asked questions