You own software you did not write
The people who wrote it are gone, nobody knows what is safe to change, and every release is a coin flip.
The problem
It arrives one of two ways. An acquisition brings a codebase along with it, or a contractor stops answering and leaves one behind.
Either way you now own software nobody on your team wrote. The tests are absent, or present and lying. The documentation describes an earlier version. Every change carries a risk nobody can size, so changes stop being made — which makes the next one riskier still.
The instinct is to rewrite. That is usually the most expensive available option, and it discards behaviour that turned out to matter.
How we approach it
-
Read it before touching it — architecture, dependencies, and what is genuinely running in production
-
Establish ground truth: what is actually tested, what is not, and how it really fails
-
Make it safe to change — tests around the parts you need to modify first
-
Harden it: security review, dependency currency, and the operational gaps nobody logged
-
Hand back a codebase your team can own, with the map that was missing
On evidence for this one
We have not yet published a case study for this work, so this page describes our approach rather than a result we can point at. When an engagement produces an outcome we can cite, it will appear here.
The services behind this
Ready to Scale Your Engineering?
Book a free discovery call. We'll discuss your challenges and explore whether we're a good fit—no sales pressure.
Book Discovery CallNo commitment required