Debugging & Bug Hunting

Enough to observe: logs, a read replica or database access, and ideally a staging environment where the failure can be reproduced. Read access is usually plenty — the goal is to understand the system, not to change it until the cause is proven.

You get everything I found and a written assessment at the end of the time-box, including what has been ruled out. That has real value on its own, because it stops your team re-searching the same ground. And you have not signed an open-ended engagement.

Yes, though the fix is usually the small part. Once the cause is proven the change is often a few lines. What matters more is adding the test or alert that catches it next time, which is included.

Usually because a fresh pair of eyes has no attachment to the theory everyone has been chasing. Long-running bugs tend to survive because an early assumption was wrong and never revisited. I start by questioning the assumptions, not by reading the code everyone has already read ten times.

Yes — that is the normal case, and it is a lot like reverse engineering. The database, the logs and the running system will tell you what is happening if you read them carefully enough. Access and a reproducible example matter far more than prior familiarity.

A fixed-fee time-boxed investigation. You get everything I have found and a written assessment at the end of the box, whether or not the cause was pinned down. That caps your risk and keeps me honest about progress.