Codebase Recovery & Stabilisation

Codebase recovery: stabilise first, then refactor safely

You inherited code that's too risky to touch and too critical to ignore. We find out what's really there, make it stable, then refactor it step by step, with no hero rewrites. You get a written recovery plan within two weeks.

Start a project

See our work

Organisations we've built for

Best for

When codebase recovery is the right move

If one of these sounds like your code, we can help.

Inherited code

The team or agency that built it has gone, and nobody knows what's safe to change.

We map the code, the dependencies and the risks, and write down what we find, so it's never knowledge in one person's head again.

Failed MVP

The first version works in demos, but breaks with real users and real data.

We stabilise the parts users depend on first, then decide with you what to keep, what to fix and what to rebuild.

Releases that break

Every release breaks something else, so releases get rarer and riskier.

Tests around the critical paths and a deployment pipeline first, so each change is checked before it goes out.

Tech debt

Tech debt blocks the roadmap, and leadership won't fund a clean-up without a reason.

A recovery plan with the risks, the costs and the order of the work, written as a business case leadership can sign off.

What you get

What a recovery gives you

A codebase your team can change again, and a clear record of how it got there.

Review and risk register

The code, architecture, dependencies and security reviewed, with each risk ranked by impact and effort.

Recovery plan

What to fix first, what to refactor later and what to leave alone, with the order, the effort and the reasons.

Stabilisation

Tests around the critical paths, monitoring, and fixes for the issues behind your incidents.

Safe refactoring

Changes in small steps behind tests, each one releasable on its own, instead of a rewrite.

Every recovery includes

A written recovery plan within two weeks

Outdated frameworks and dependencies upgraded

Documentation of what we found and changed

A handover your team can carry on from

How we deliver

From fragile to stable, without a rewrite

The same three steps as every project we run, with the code reviewed before anything changes.

Plan

We read the code, run it and talk to the people who use it. You get the risk register and the recovery plan, with a list of what we won't touch.

Thin slice

The riskiest path stabilised first, behind tests and monitoring, with a demo every week. Then the next one, in the order the plan sets.

Launch and handover

Documentation of the system as it now is, a working pipeline and a handover, so your team can keep changing it safely.

How we work

Security and data

Security gaps found and closed

Inherited code often has security problems nobody has looked for. The review looks for them.

Security in the review.

Vulnerable dependencies, secrets in the code and weak access control are part of the first review, ranked with the other risks.

Access only to what we need.

We work in your repositories and environments with the access the work needs, under a data processing agreement. Every engineer can sign an NDA if you want one.

No production data copied.

We reproduce issues with synthetic or anonymised data, never with copies of production personal data.

How we protect your data

Sectors and technologies

Where we've built, and what we work in

Sectors

Our engineering team has built and supported production systems for hospitals, banks, cooperatives and a national geospatial institute, where downtime and wrong data aren't an option.

Healthcare

Financial services

Logistics & mobility

Public sector & geospatial

Technologies

We work in the stack you have. These are the technologies our engineers know best.

Java

.NET

Python

Node.js

TypeScript

React

Angular

PostgreSQL

FAQ

Questions about codebase recovery

A structured way to bring a fragile or inherited system under control: we review the code, the architecture and the dependencies, write a risk register, and stabilise the system step by step with tests and small releases. Typical cases are software left by a former vendor, a prototype that became the product, or a system nobody dares to change.

Usually fix it. A rewrite stops new features for months and brings new bugs, while the old system still has to run. We recommend rebuilding only the parts where the review shows that fixing costs more, and the recovery plan says why.

Access to the code repository, a test or staging environment if there is one, and an hour with the people who know the system best. Documentation helps, but we don't expect it.

We review the code, the architecture and the dependencies, run the system and talk to the people who use it. At the end you get the risk register and a written recovery plan, so you can decide on the next step with the facts in front of you.

Yes. Changes go out in small releases behind tests, and the riskiest areas get monitoring first, so problems show up before your users notice them.

That's common. We add tests around the critical paths first, the ones users depend on, so the next changes can be checked. Coverage grows with every part we touch.

Yes, and it's the most common starting point. We work from the code, the running system and the people who use it, and write down what we learn so the knowledge no longer sits in one person's head. Access to the repository is the one thing we need first.

Yes. Your team reviews our changes before they merge, and we document what we find as we go, so the knowledge stays with you. Our team lead plans and runs our engineers' work.