Elusive bugs blocking production. Critical systems failing under load. Applications whose original developers are long gone. 35 years going into other people's code — diagnosing root causes and fixing what thousands of users depend on.
It runs the business, and nobody fully understands it anymore. The people who built it left years ago. The documentation was never written. Every fix breaks something else, every consultant who looks at it quotes a rewrite, and meanwhile there's a bug in production that three teams have already failed to find.
This work has a different texture from greenfield engineering: it's code archaeology under pressure. It rewards the engineer who has read other people's code for three decades — across languages, eras and disciplines — and who treats "nobody knows how it works" as the starting condition, not the excuse.
Four situations I'm repeatedly hired for. The common thread: mission-critical code, no safety net, and a business that can't stop while it gets fixed.
The defect nobody can reproduce, the performance collapse that only happens under real load, the integration that corrupts data once a week. I go into the code, instrument it, and find the root cause — not the symptom.
Mission-critical systems that thousands of users depend on are the usual setting.
Systems whose authors are gone and whose documentation never existed. I study the source, reconstruct the knowledge, write the documentation — and then extend the system safely, for years if needed.
Done repeatedly: from taking over a cartographic platform with zero support from its creators to a decade extending another company's abandoned production system.
Disaster recovery, compromised servers, hard deadlines that can't move. The engineering doesn't get worse because the clock is running — verification and discipline are what keep an emergency from becoming two.
History includes recovering infrastructure from virus infection and bringing production servers back from failure.
A rescue isn't finished when the fire is out. The system leaves my hands with documentation, tests around the fragile parts, and a roadmap — so your team can own it again and the next emergency doesn't happen.
If the honest answer is that something should be replaced, you'll hear it with the evidence attached.
100% remote, in English or Spanish. Urgent problems get an answer fast; long takeovers get a plan.
Production is failing now. Direct engagement on the live problem: diagnose, fix, verify, and leave a written account of what happened and why it won't recur.
Fixed-scope pursuit of a defect that has resisted your team: reproduction, instrumentation, root cause, fix. If it can be triggered, it can be found.
Assume responsibility for an application nobody owns: study, document, stabilize, then extend it safely — while your users keep working on it.
Ongoing senior guardianship of a fragile system: the person your team calls before touching it, and the one accountable when something moves.
A selection from the full project history — each row links to the detailed record. Much of this practice is NDA-bound and never appears publicly.
The questions people actually ask when production is down or the last developer just resigned.
No — that's the normal starting condition of this practice. The method is always the same: study the code as it really is, reconstruct the knowledge, write the documentation that never existed, and only then change things — safely, while the business keeps running.
Almost never. A rewrite is usually the most expensive and riskiest option on the table — and it's where many rescues come from in the first place. The default is to stabilize, document and extend what already runs the business. When rewriting really is the better path, you'll hear it with evidence attached.
Contact through LinkedIn and describe the situation; urgent production problems get an answer quickly. Work is 100% remote, in English or Spanish, which removes most of the usual delay.
Yes — a substantial part of my project history is NDA-bound and never appears on this site. Confidentiality is the default working mode of this practice.
Then skip the pleasantries — send me the situation as it stands, ugly parts included. The honest version is the one I can help with.