Code review

Before a vendor change or a bigger investment, the question is not whether the code is tidy. It is what happens if the key person leaves, how long a change takes to reach production, and which dependencies will need a big upgrade the day a security fix only exists for newer versions.

What you get

A written summary you can read without being a developer, with the risks ranked by what they could cost and how likely they are. It is a screening, not a full audit: we point out what smells and where it is worth digging deeper. We separate what should be fixed first, what can be planned in later, and what looks bad but rarely changes and can therefore wait. We also write down what we could not judge, and why.

What we look at

• Dependencies. Which are several major versions behind, and what does catching up take? The cost does not show day to day, but the day a security fix only exists for a newer version, the upgrade becomes urgent.
• Lead time and deployment. How long from commit to production, and how often do you release?
• Test coverage on the most important flows. It tells you how much of a change can be checked automatically, and how much has to be clicked through by hand.
• Change frequency from the version history. Which files change most? That shows where the work happens and, together with the interviews, why.
• Knowledge distribution. Which parts are understood by only one person?

How long does a review take?

It depends on the size of the system, how many systems are included and how many people we need to talk to. We give an estimate once we have seen the codebase and know who we can interview. We do not skip the interviews: the version history says what changed, but not why something was built the way it was. If the review points to a part worth replacing, legacy modernisation is how we would go about it.