Audit, repair and takeover after another developer
Understand unfamiliar code, identify root causes, fix the critical path and create a safe plan forward.
What this work involves
When a live project is fragile, slow or abandoned, I reproduce the problems and fix causes in priority order. A full rewrite is an option only when evidence supports it.
Who it suits
- Owners of a system that works but feels unsafe to change
- Companies after a contractor or developer leaves
- Teams that need a second view of architecture and risk
Questions answered before delivery starts
- What works and what fails?
- Which workflows are business-critical?
- What is known about earlier decisions and debt?
- What budget is available for repair rather than a rewrite?
How the work proceeds
Diagnosis
Run the system, inspect the structure and reproduce failures.
Prioritise
Separate urgent fixes, later work and areas not to touch.
Change carefully
Make targeted fixes and test connected workflows.
Hand over
Document what changed, what remains and how to proceed.
Boundaries and working rules
- Rewrite only when it is genuinely safer and less expensive
- Diagnose before budgeting
- Test changes against real workflows