Code audits and technical due diligence

If you are carrying software that nobody currently employed can fully explain, you are carrying a risk that has never been priced.

A code audit prices it.

When people ask for one

The original developer moved on. An agency relationship ended and the handover was thin. An acquisition arrived with a system attached. A founder built the first version and it quietly became production. Or a rebuild has been proposed and the person proposing it is also the person who would be paid to do it.

What we look at

Security exposure, including how credentials, data and access are handled. Maintainability, meaning whether a competent engineer who did not write this could work in it. Architecture and whether it will hold at the volume you are planning for. Dependencies, licences and anything unsupported. Test coverage, deployment and what happens when something breaks at two in the morning.

What you get

A written report in plain language, with the technical detail in an appendix rather than in the way. Findings ranked by severity and by cost to fix. And the answer most clients are really buying: an honest comparison of extending what exists against replacing it, with numbers on both.

That answer surprises people in both directions. Systems assumed to be disposable are sometimes structurally sound and worth investing in. Systems still having features added should sometimes have been retired eighteen months ago, and every addition since has made the eventual migration more expensive.

An independent second opinion

Most of this work is for companies that already have a development partner and are not looking to replace them.

The situation is usually the same. You have a team building or maintaining your software. They tell you it is in good shape, or that it needs rewriting, or that the next phase will take six months and cost what it costs. Any of that may be entirely true. You have no way to check, because the only people who can read the system are the people who wrote it, and that is an uncomfortable position to make a large decision from.

An audit gives you a third party with no stake in the answer. We read the system and tell you what is actually in it, in language you can take into a board meeting or a budget conversation without needing an engineer to translate.

That includes telling you when the right answer is to keep what you have, change nothing, and carry on with your current team. It happens often, and it is a perfectly good outcome. An audit that always concludes "rebuild it, with us" is not an audit. It is a sales call with a report attached.

When something else fits better

If the audit says the system is sound and simply needs looking after, that is cloud deployment and ongoing support. If it says the right move is to rebuild, we will tell you which of our build services fits and why.