RawData

Picking a project back up after a year, and reading what I'd actually built

Reviving BoomerClip meant a new machine, scripts that assumed an old one, docs that described features that never existed, and an honest code review.

BoomerClip was built in May and June 2025, then set aside. In September 2026 I opened it again.

If you've ever come back to your own code after a long break, you know the feeling. You remember what you meant to build. The code remembers what you actually built. Those aren't the same thing.

Step one: make it run at all

The project had been written on a Mac. I'm on Windows 11 now, and it showed immediately.

The dev restart script assumed my old machine. It had a hardcoded path to a project folder on a Mac that no longer exists, used brew to start services, and opened gnome-terminal, which isn't on a Mac or Windows. I rewrote it to find the project root on its own, free the dev ports with whichever of lsof or netstat exists, and check Redis and MongoDB directly instead of assuming how they were installed.

Two of the session scripts blocked waiting for a keypress, so they couldn't run unattended. Those prompts are gone.

The production deploy script worked out the project root one directory too shallow, a leftover from when the scripts had moved folders. It would have run everything from the wrong place.

npm 11 quietly installed incomplete packages. bcrypt, ffmpeg-static and sharp all fetch platform-specific binaries in an install script, and npm 11 doesn't run those scripts unless you explicitly allow them. So the install finishes without complaint, just without the parts those packages need to work. Listing them under allowScripts in package.json fixed it.

Then the services: MongoDB Server and Memurai Developer (a Redis-compatible server that runs natively on Windows), both set up to start automatically. After a clean npm ci for the server and the client, the API, login and admin panel came up.

Step two: can it still do the one thing?

Recording and uploading worked in Chrome, and shared links played. That was the good news.

Manual testing also turned up two regressions in the viewing flow, the part that decides when a recording gets deleted. Those got a whole session of their own, and they're the subject of the next post.

Step three: the docs had drifted from the code

This was the humbling part.

BoomerClip's documentation, much of it written in the last burst of sessions before I set the project aside, described an app that was more finished and more "enterprise" than the one in the repo. When I did a full code sweep, reading every area rather than trusting the docs, I found that several things the docs described simply weren't there:

None of that is unusual for a side project that grew fast. But documentation that describes features you don't have is worse than no documentation, because it's confidently wrong. Future me, or anyone else, would have made decisions based on it.

So the review got written up properly: findings sorted by area (server, viewing, recording, accounts, enterprise and deploy), the results of automated checks, a list of the documents that were false, and a five-phase fix plan. Every document the review found inaccurate now has a warning banner at the top pointing to the review, until a final truth pass rewrites it.

The decisions that came out of it

Three decisions came out of the review, and I recorded each one with its reasoning:

  1. Fold in and drop the enterprise layer. Keep what's actually used, delete the rest.
  2. One video player, with per-browser adapters, instead of four separate players.
  3. Deletion is a server guarantee. Right now it depends too much on the browser politely saying goodbye. The review found ways a recording can be fetched or kept that skip deletion entirely. For an app whose whole promise is "seen once, then gone", that's the one thing that must be true.

The review also flagged security issues to fix before BoomerClip goes anywhere near a public server. It isn't deployed, and it won't be until those are closed.

Where it stands

BoomerClip is running locally, not deployed. The review's fix plan has five phases:

  1. Clear the ground: remove the unused enterprise code, get the production build compiling, add automated tests.
  2. Make deletion a real server guarantee and fix the security findings.
  3. and 4. One video player for every browser, and a more reliable recorder, then re-test in Edge and Firefox.
  4. Bring the privacy policy, terms and documentation in line with the code, then the first deploy.

It's less finished than the old docs claimed. But for the first time, the docs say exactly how finished it is.

Update: phase 1 is done. How that went is in the next post.

The sun is shining. ~ Jer