Technical due diligence on the code, not the pitch

A score out of ten overall and across ten dimensions, findings grouped under each with the file they live in, an estimate of what leaving each one alone costs, and the three things worth fixing first. Then a call. We do not deliver three hundred lint warnings and call it diligence.

Worse than the people selling them expect. Across 29 codebases we did not write, spread over 12 organisations, the first read averaged 4.21 out of 10. 3 of those 29 came back at 7 or above and 7 came back under 3. On the same scale, our own 57 repositories average 6.03 — we publish that rather than a 9, because a scale where everything we touch scores 9 would tell you nothing about anything else.

Honest enough to describe its own holes. The bot was scheduled 156 times against client repositories; 126 of those runs returned a default three-line report with no files analysed — a permissions or size failure rather than a read — and only 30 produced a report with findings in it. The averages here are from those 30. Counting the failures as audits would have made the corpus look five times bigger and pushed the mean toward 4 by arithmetic rather than by evidence. The window is September 2025 to January 2026.

Testing, by a distance. It was among the top three risks in 18 of 29 codebases, and 19 of them scored 3 or less on testing alone — mean 2.9 out of 10, against 4.95 on our own code. After that: authentication and access control in 12, error handling in 12, scalability limits in 7, and credentials or API keys committed to the repository in 6. Documentation and DevOps sit at 3.53 and 3.5, which is what "the team that built it has left" looks like as a number.

Yes, and occasionally it is — 3 of 29 scored 7 or above on a first read. The more common outcome is a middling score with two or three genuine risks, because that is what working software looks like after a few years of shipping. A first audit rarely comes back above seven, including on our own repositories, which is how we know what a realistic number is.

We can build, so the conflict is real and worth naming rather than denying. Two things limit it: the report is written before any remediation is scoped, and you can buy the audit as the only deliverable and tell us so up front. It is also a perfectly good outcome to hand our report to your own team or to another vendor — that happens, and the report is written to be usable that way.

A week for one codebase, two for a large or multi-service estate. Diligence windows are usually shorter than anyone wants, so say the date on the first call — if the timetable is not real we will say so then rather than deliver a thin read on the day it is due.

We are not a regulatory consultancy and we do not issue formal security certifications. We have not taken a product through FDA clearance. If your diligence needs a penetration test with a signed attestation, or a SOC 2 audit, hire the specialists who do only that — our read covers the code, the architecture and what it will cost to own.