A code audit that tells you what you’ve actually got
A code audit is a senior engineer reading your codebase, infrastructure and delivery process end to end, then telling you plainly what’s risky, what’s fine, and what it will cost to fix. It’s for owners who aren’t sure what they’ve got – after an agency handover, a key departure, or a few years of shipping fast.
The deliverable is a ranked risk list with effort estimates, so you can make decisions with it on Monday morning.
When a codebase audit makes sense
- You inherited it. An agency or freelancer built the product and has moved on, and your new team keeps saying “we should rewrite this.” Before you spend a year on that, find out whether they’re right.
- Delivery has slowed and nobody can say why. Features that used to take a week now take a month. Sometimes it’s the code; often it’s the process around it. An audit separates the two. See also why engineering teams slow down.
- It was built quickly with AI tools and now has paying users. Generated code tends to work on the happy path and fail in ways nobody has looked at. That overlaps with vibe-coded app rescue.
- You’re about to hire a CTO or lead and want an independent view of what they’re walking into.
- You’re about to raise or sell and want to find the problems before the other side does.
What I look at
A source code audit that only reads code misses half the picture. I look at the system as it runs and the team as it works.
- Structure and design. Where the boundaries are, how tangled the dependencies are, whether the data model matches the business.
- Correctness in the places that cost money. Payments, billing, permissions, anything multi-tenant, anything that sends email to customers.
- Tests and deployment. What’s covered, whether the tests catch real bugs, how a change gets to production, and how you roll back.
- Dependencies and runtime versions. What’s out of security support, what’s abandoned, and how hard each upgrade is.
- Operations. Logging, monitoring, backups, restore history, error rates and the incidents nobody wrote down.
- Security basics. Secrets in the repo, authorization checks, injection risks, admin tooling exposed to the internet.
- Performance. Slow queries, missing indexes, N+1 patterns, and the endpoints that will fall over first under load.
The deliverable: a ranked risk list
Most software audit reports fail the same way: long, evenly weighted, and impossible to act on. Mine is built around a single ranked list. Each item has:
- What’s wrong, in a sentence a non-engineer can follow, plus the file paths for the engineer who has to fix it.
- Why it matters – the failure it causes and how likely that is.
- Effort to fix, as a range in engineer-days or weeks.
- A recommendation: fix now, fix when you next touch it, or accept and document.
On top sits a short summary and an honest answer to the question you actually care about: keep, refactor, or rewrite. Usually it’s refactor. My guide on rewrite vs refactor explains why.
What a code audit isn’t
It isn’t a penetration test. I’ll catch common security mistakes in the code and configuration, but a pentest is an adversarial exercise against the running system by a specialist. If the audit suggests you need one, I’ll say so and help you scope it.
It isn’t due diligence. Technical due diligence is done for an investor or acquirer and frames everything around deal risk and price. A code audit is for you, the owner, and frames everything around what to do next.
It isn’t a line-by-line code review service. If you want ongoing review of every pull request, that’s a different engagement – or a process problem worth fixing inside the team.
How it runs
- Short call. You tell me what you’re worried about and what decision the audit has to support.
- Access. Read-only access to the repositories, hosting and error tracking, and an hour or two with whoever knows the system best.
- Review. I build it, run it, read it, and trace the paths that matter most to your business.
- Report and walkthrough. The ranked list, the summary, and a call to go through it with you and your team.
If you want help acting on the findings, the natural next step is a two-week sprint where I fix the top items alongside your team. No obligation; you can take the list and run with it yourselves.
Why me
I’ve spent more than twenty years shipping production software, including 200+ projects through the studio I co-founded and sold, and the payment platform at Yola and payment integrations for BLU Loyalty. I’ve read a lot of codebases in a lot of states. That means I can tell the difference between a codebase that looks bad and one that is bad, which is most of what you’re paying for.
Questions
What is a code audit?
A code audit is an independent review of a software codebase and the way it’s built, tested and deployed. It identifies risks in correctness, security, maintainability and performance, and ideally ranks them by impact and effort so the owner knows what to fix first.
How long does a codebase audit take?
It depends on the size of the system. I agree scope and timing with you up front. Larger systems take longer, and I’ll tell you up front if I think the scope needs cutting to stay useful.
Which languages and stacks do you audit?
Mostly web and SaaS stacks: PHP and Laravel, Ruby on Rails, Python and Django, JavaScript and TypeScript front ends, PostgreSQL and MySQL, and the usual cloud platforms. If your stack is outside that, I’ll say so on the first call.
Will the audit tell me whether to rewrite?
Yes, with reasons. Most of the time the answer is to refactor in place and replace the worst parts incrementally. A full rewrite is occasionally right, and when it is I’ll explain what makes your case the exception.
Not sure what you’ve got?
Tell me how the codebase came to you and what’s worrying you. I’ll tell you whether an audit is the right next step, or whether something cheaper will do.
GMT+2 · Full EU overlap · US East mornings