Reza Golkhandani // Senior Software Engineer | Backend platforms
The Audit Ledger That Turned Bug Hunts Into Permanent Fixes
Quality | Process | Frontend
The Audit Ledger That Turned Bug Hunts Into Permanent Fixes
The goal
Before every release of the service-business platform, I run an audit cycle: authorization, layout, time zones, data integrity, and the commercially critical booking page. The goal was to make each cycle find new problems rather than the same ones, and to fix classes of bugs rather than instances.
The approach
One ledger with memory. Every finding gets an id, a status, and a remediation plan. Findings are updated by id, never logged twice. Every remediation states whether it closes a class or an instance, and classes go first.
What I built
Design tokens with a guard. The audit found dozens of CSS variables referenced but never defined, including the primary colour behind the booking page's main button. Defining them took an hour. The lasting fix was a build-time check that fails on any variable with no definition and no fallback.
Time zones with a rule. Every date-formatting call was routed through one helper, and a lint rule now bans the raw methods outside that file.
Data that is read or removed. A settings field with a column nothing consumed was removed rather than left as a silent promise. An event log that could assert something untrue was reworked to record only what actually happened.
Checks that are real. One audit step had been passing every cycle while testing nothing, because its tool never changed the rendering viewport. It was deleted rather than left as false coverage.
A priority order. Security first, then anything that closes a class, then correctness and UX, then data hygiene, with the riskiest single change last and alone.
The result
Each of the next cycles surfaced only new findings. The most visible one, the invisible booking button, cannot recur because the build refuses it. The ledger is a few hundred lines and is read before every cycle and appended after.
Takeaways
- Fix the class before the instance, then add the check that fails next time.
- A check that silently never runs is worse than no check. Delete it or make it real.
- Store nothing you do not read. A record that asserts something untrue is worse than no record.