R.GOLKHANDANI
Home / Blog / Posts / Audit Cycles
online--:--:--

Reza Golkhandani // Senior Software Engineer | Backend platforms

The Audit Ledger That Turned Bug Hunts Into Permanent Fixes

Quality | Process | Frontend

01

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.
02

Connect with Me