Code Audit and Technical Due Diligence, With a Plan Attached
An independent look at your codebase: security, performance, tech debt, and what to fix first.
Someone is about to make an expensive decision about a codebase they did not write. Maybe you are acquiring the company. Maybe you are the board and the roadmap keeps slipping. Maybe you inherited the thing and need to know how bad it is before you promise anyone a date.
We read the code, run the tools, talk to the engineers who live in it, and write down what we found — ranked by how much it actually hurts and how much it costs to fix. Four angles: security risks, performance bottlenecks, tech debt where it genuinely bites, and whether the repo is bearable to work in. That last one predicts your hiring and retention more than people expect.
What you get
A decision you can defend
Findings ranked by severity and rough effort, in language a non-technical founder can skim and an engineer can act on. If the answer is "this is fine, ship it", we say that too.
A 30/60/90 you can actually run
Not a backlog dump. A short, ordered list of what to do first, what can wait a quarter, and what to simply live with.
No dependency on us
The report stands on its own. If you want help executing the fixes we can, but nothing in the deliverable is written to make that necessary.
Included
- Security risk review
- Architecture and scalability assessment
- Tech debt mapped to delivery impact
- Developer experience and onboarding friction
- Dependency and supply chain review
- Written report with severity and effort ratings
- 30/60/90 day remediation roadmap
Selected work
A few projects where this was the job.
Circuit
Digital asset security platform for managing and protecting cryptocurrency vaults. Features multi-provider integration for connecting various wallet and custody solutions, organisation-level access controls, and a sleek dark interface designed for security-conscious users managing digital assets.
Receipt Approval
Enterprise invoice and document approval platform for streamlined accounting workflows. Features pending task management, supplier document tracking, invoice preview with detailed metadata extraction, notification system, and IFS integration for seamless financial operations.
Navigator
Team coaching and performance management dashboard designed for Pahl Consulting. Features organization-wide status visualization with radar charts tracking Quality, Quantity, and Direction metrics. Includes top performers leaderboard, team comparison tools, and detailed member analytics with sortable data tables.
Common questions
What is actually inside a code audit?
Four angles, usually. Security risks, performance bottlenecks, tech debt and where it actually hurts, and developer experience (is this repo bearable to work in). We read code, we run tools, we talk to your engineers. Findings land in a written report with severity and a rough effort estimate.
How long does an audit take and who needs to be involved?
Usually one to two weeks, depending on codebase size. We need read access to the repo, a short intro from someone who knows the system, and maybe a couple of calls when we hit something weird. Your engineers do not have to babysit us. That is kind of the point.
What do we walk away with?
A written report that a non technical founder can skim and an engineer can act on. Issues ranked by severity and effort, plus a rough 30, 60, 90 day roadmap. No fluff, no 80 page PDFs nobody will read. If you want us to help execute the fixes after, we can. If not, the report stands on its own.
Can you run this as pre-acquisition technical due diligence?
Yes, and it is a common reason people call. The shape is the same, the audience is different: the report is written so an investment committee can read the summary and a CTO can read the detail. We flag the things that change a valuation or a earn-out structure — key-person risk, licensing, undisclosed third-party dependencies, and whether the roadmap the seller presented is buildable by the team that exists.
Will this disrupt the team whose code you are reviewing?
Barely. We need read access and one intro call. Beyond that we work from the code and come back with questions in batches rather than tapping people all day. If the audit is part of a deal and the team does not know about it, say so upfront and we will work purely from the repository.
