Before acquiring a product
Technical due diligence before the price is agreed and a hidden rebuild becomes your problem.
CODE AUDIT & REFACTORING
An honest assessment of a stalled, inherited, or acquired codebase before deciding whether to continue, improve it, or replace it.
WHEN YOU NEED ONE
Technical due diligence before the price is agreed and a hidden rebuild becomes your problem.
A developer left, an agency was replaced, or the project changed hands without a useful handover.
The previous team said it was nearly finished, but the reality does not match the status report.
A large decision that should be based on evidence rather than the instinct that the code feels messy.
Every feature takes longer than the last and nobody can name the structural reason.
The state of the codebase tells you what kind of developer or team you actually need next.
WHAT I LOOK AT
The audit focuses on the technical choices that determine whether the system can safely support the work you need next.
How the system is organised, what it can support, and where future work will meet resistance.
Readability, consistency, duplication, outdated packages, and whether a new developer can change it safely.
Authentication, authorisation, credentials, dependency vulnerabilities, schema integrity, and extension risk.
Obvious bottlenecks, testing, deployment, documentation, and knowledge trapped in one person’s head.
WHAT YOU GET
The output is written for the person making the commercial call as well as the developer who may carry out the work.
Continue, refactor incrementally, or rebuild, with the reasoning behind the recommendation.
Security problems and structural faults that deserve action regardless of the chosen path.
The commercial cost of each path, so the next decision is not emotional or based on a guess.
Work ordered by risk and impact rather than by the easiest ticket to close.
A direct account of what could be assessed, what could not, and why that uncertainty matters.
THE NEXT DECISION
Refactoring is incremental work that makes a codebase maintainable without stopping delivery. It restructures one area at a time, keeps refactor commits separate from feature work, and adds protection around anything being changed.
A rebuild is only justified when the architecture cannot support the next requirement, the technology is unsupported, the data model is fundamentally wrong, or fixing it exceeds replacing it. Ugly code alone is not enough.
Continue
When the system is sound and the real issue lives outside the code.
Refactor
When the product works but delivery needs to become safer and faster.
Rebuild
When the foundation cannot carry the work that matters next.
THE PRINCIPLE
Developers reach for rebuilds too quickly because writing new code is easier than understanding an existing system. That instinct is often expensive and wrong.
The goal is not a codebase that matches my preferences. It is a codebase your team can work in with an honest view of the trade-offs.
“The right recommendation is the one that remains true after I am no longer involved.”
The operating principle
COMMON QUESTIONS
The practical questions before repository access is shared and a major technical decision is made.
Usually three to five days depending on the size and condition of the system. Large systems take longer, and that is clear before work starts.
JavaScript, TypeScript, Node.js, React, React Native, WordPress, and Shopify. Outside these, I would be guessing and will say so.
The most common recommendation is incremental improvement. A rebuild is only sensible when the architecture, data model, or unsupported technology makes it unavoidable.
Often, after the audit has established what both sides are actually agreeing to.
Yes, within the technologies listed above.
That is normal. The audit works from the code, infrastructure, and documentation that exist.
Give me repository access and a few days. You will get a straight answer about what you are holding and what each viable option costs.