The Go-Live Audit

· Zoe · 6 min read

The Unglamorous Work

Consistency is easier when you're working on something that shows visible progress.

My wife and I both got sick for a few weeks in December. It led to our driveway not getting cleared of snow as well as I would have liked. We had some great weather recently, so I've been chipping away at the ice and snow buildup at the end of our driveway. We even went and cleared out both storm drains further down the street so the melting ice and snow could stop flooding the road. It's ongoing work — not done, probably won't be until spring — but every time we pull in or head out, there's visible progress.

!Ice buildup at the end of the driveway

And tonight we're expecting another 5-10cm of snow. That's a setback, but we keep going anyway. The driveway is the kind of work where progress is visible. My wife, our daughter, and I all notice it. That visible progress makes it easier to stay consistent.

Preparing a SaaS application for go-live is the opposite. Nobody sees it. There's no new feature to announce. Users will never know you removed 5,500 lines of dead code. But the bones of the application matter, and that unglamorous work is what keeps the foundation sound.

A Familiar Problem

Tech Debt is a term I loved to use when I worked at MSPs. We would onboard a new client and one of the first things I always did was to discovery any critical or blocking tech debt. You would be amazed how many times a client would be onboarded and I would find their Active Directory and local DNS still pointing to an old domain controller that hasn't existed for years. I usually found this through the DFSR event log with Event 4012.

"The DFS Replication service stopped replacation on the folder with the following local path: C:\Windows\Sysvol\domain. This server has been disconnected from other partners for ___ days, which is longer than the time allowed by the MaxOffLineTimeInDays parameter."

The longest I had ever seen was in the 1400 days range.

So Why Does This Matter

Why am I talking about this in a blog post about Unified DNS? Well, I've been working on preparing it for go-live. That means combing through and finding any "TODO" notes I've left. Finding items I replaced but forgot to remove at the time. Removing partially implemented features that I determined would not have a real benefit to most users.

One such feature was a profile avatar so that users could upload an image to use as their profile picture. Sure, most platforms have this.. But when I look at our platform, it just really isn't needed and I don't see that feature getting much use, so it got removed. I'm not looking to stuff this platform with features just to make the features list longer. The platform already generates a simple icon with the initial of the user's first name. For 99% of users, that's all it needs to be.

Another TODO list item was to modify MFA setup to require the user to enter their password before setting up MFA. It's a little item in the grand scheme, and is one that would have gotten missed before the go-live if this audit hadn't been completed.

The Three Passes

I'm writing this dev diary in-between builds. This has been going on for 2 or so weeks now? First pass was a manual code review. I started by reading through the codebase with fresh eyes, looking for the obvious stuff: orphaned page components that had been replaced, scrapped features that were half-removed (Example: the avatar upload on the profile page), TODO stubs that referenced features I decided not to build, and deprecated service methods that nothing called anymore. This first pass was about things I already knew were dead code.

Second pass was a security-focused review. Once the obvious dead code was gone, I was able to look specifically at what shouldn't ship to production from a security standpoint.

Third pass is a systematic sweep. This is the one I am currently on. With the low-hanging fruit handled, I ran a structured audit across the codebase looking at ten specific categories:

  1. Orphaned files
  2. Dead exports
  3. Commented-out code
  4. Unused imports
  5. TODO/FIXME comments
  6. Duplicate code
  7. Empty stubs
  8. Deprecated patterns
  9. Test/debug artifacts
  10. Stale routes

This is where the bulk of the findings came from. Entire controller files that were never wired up to routes, a Zustand store that no component imported, barrel export files that nothing used, and ~80 lines of \[DEBUG\]-prefixed logging scattered across 8 files.

Prioritizing the Findings

Each sweep produced findings that I then categorized by priority:

Each commit was independently deployable. If any commit introduced a problem, I could isolate exactly which category of change caused it. I never mixed risky behavioral changes with safe dead code removal. The code would run on the private test environment for a few days before the next build would be pushed. That gave testing periods between each to make sure nothing was unexpectedly broken.

The Results

The results so far are staggering. 16 files deleted, 37 files modified, 5,542 lines removed. With more work planned, this is the less than glamorous work. It doesn't look any different to users. They don't see that work, there's no new features for them to use. We do that work regardless, because it makes us better. It keeps the foundation in order for a more sound platform.

The P2 items and the logger migration will get their own sprint after launch. For now, the foundation is solid, and the codebase is in a state we can trust. That means when we do start building the next wave of features, we're building on something more sound than it was before. Go-live is close. Stay tuned.