Built with Claude Code.

The thing that works for me isn't describing what I want and taking whatever comes back. It's closer to working with someone who knows what they're doing but has never seen my setup. I say what I want, it goes and looks at what's actually there, and it tells me which of my assumptions were wrong before writing anything.

That last bit is where most of the value has been. Nearly every project below turned up something I had wrong at the start. A folder that isn't named what it looks like it's named. A backup that was running but useless. An iPad that turned out to be a different iPad. None of that comes up if you just describe the problem, and all of it would have broken the finished thing.

Everything you're looking at. It started in February 2026 as one page and it's now 178 commits of tinkering. No framework, no build step, nothing to install. Just HTML, one stylesheet, and a bit of JavaScript.

A few things it does that you wouldn't guess from looking at it. The changelog writes itself from git history and filters out the automated commits so only real changes show up. The Library page pulls live from Letterboxd and Goodreads. There's a search box on the home page that indexes every page.

There's also a guestbook running on a Firebase database with App Check turned on through reCAPTCHA. That sounds tidy written down and it cost me an entire evening, because Firebase had auto created a key that didn't show up in any console I could get to, which meant I couldn't add domains to it and couldn't figure out why every call was failing.

Probably the most useful category, mostly because these got built against real deadlines.

There's an AUD sprint dashboard for the CPA exam. A day by day plan for a two week run at the Auditing section, with daily simulation and multiple choice targets weighted toward whatever I was worst at. The checkboxes save to the device so closing the tab doesn't lose anything. I rearranged it something like a dozen times as my actual pace drifted from the plan, which is honestly the real use case.

For Accounting Information Systems at Stern I built a full set for each exam: study guide, practice test, review quiz, flashcards, a drill of the hardest questions, and exam style questions. One set for chapters 7, 14 and 19, another for the cybersecurity final on chapter 16 and the CIS Controls.

And for FAR there's a study guide and a formulas and mnemonics sheet, built from my own lecture notes plus my handwritten exam reviews. The handwritten ones are pure ink with no text in them at all, so they had to be rendered as images before anything could read them. Both are set up to print properly because the whole point was having them on paper.

One thing worth saying: the notes those came from don't cover several topics that actually get tested, and the study guide says so instead of quietly filling in the gaps. A study tool that pretends to cover more than it does is worse than not having one.

A focus timer, built because every one I tried was either an app I didn't want to install or a website buried in ads.

You can set the focus, short break and long break lengths, get a long break every so many cycles, have it roll into the next phase automatically, and it plays a sound and fires a browser notification when a phase ends. There's a label for what you're working on and a running count of sessions, minutes and cycles. It also holds the screen awake while a timer is running, which got added after the obvious thing happened.

A pipeline that gets a record from my turntable into a 95,000 track iTunes library on a headless 2012 MacBook Pro. It checks the files, verifies every byte across both machines, and imports in a way that iTunes can't catch halfway through.

It runs itself now. Exporting from VinylStudio is the only thing I do. Something notices the export, waits until it's actually finished writing, sends it, waits for iTunes to genuinely import it rather than just accept the files, and then notifies me with how long it took. A daily job cleans up the local copies afterwards, but only ever for albums iTunes confirms it has.

It has its own page with the four things that broke along the way and the backup problem I found by accident while building it. Read about the vinyl pipeline → There's also a technical write up if you want the atomic renames and the shell quoting.

The pipeline still depended on VinylStudio to do the recording and click removal. So I asked for my own app: a native Mac program that records a side, takes the clicks out with a detector trained on one of my own records, edits like Audacity, and hands the finished album straight to the pipeline.

OpenAI's Codex built the first five versions and ran out of usage in the middle of the sixth. Claude Code read its logs, fixed the crash it left behind, finished that version and built three more in a night: it decoded VinylStudio's repair files to get real training labels, trained a detector that finds 86% of the clicks the old one missed entirely, matched Audacity's editing commands one by one, and added a second-take comparison for patching a scratch from a better rip. Read about GrooveKeeper →

Once the vinyl pipeline was running on its own, I had no way of knowing whether it still was. So I built a small Mac app that lives in the menu bar and keeps an eye on the whole thing.

It shows what's queued, whether anything failed to import, whether the background jobs are actually loaded, and when each last ran. It also reaches across to the old MacBook Pro for uptime, how long iTunes has been open, disk space, backup age, CPU temperature and fan speeds. The icon changes when something needs looking at, so mostly I ignore it.

The temperature part needed a detour. The usual tool for reading Mac sensors wants admin rights, so instead there's a small C program on the old machine that reads them directly through IOKit and needs no privileges at all. I had to compile it on the machine itself, since the API was renamed in a later version of macOS than that laptop will ever run.

The app itself is deliberately thin. All the actual logic stays in a script that gathers everything into one blob of data, and the app just draws it. That way I can change what gets monitored without touching any Swift.

I got a second Studio Display and wanted the left one to be the left channel rather than each of them playing its own copy of the stereo mix. macOS has no setting for that, so it takes an aggregate audio device and a channel map that nothing in the interface explains.

Aggregate devices also have no volume control at all, which kills the volume keys, so this needed another menu bar app. It writes volume to both displays at once, intercepts the volume keys, and carries brightness, True Tone and Night Shift for both panels together. Brightness had to work the other way round, because those keys never reach an event tap at all — macOS handles them below that and only moves one display, so the app watches for the change and mirrors it.

The interesting part was a delay between the two panels that made everything sound smeared. The two displays are different generations and report latencies 37 milliseconds apart, which looked like a straightforward arithmetic fix. It wasn't, twice over. Read about the display setup →

The library lives on a 2012 MacBook Pro that runs iTunes 12.9.5 and nothing else, headless in another room. So it got an HTTP API and a native Mac client drawn to look like iTunes 10 — the column browser, Cover Flow, the green display, the lot.

The hard part was the iPod. iTunes syncs from a selection of ticked playlists and artists that nothing outside iTunes can read: no AppleScript terms, an accessibility tree with zero elements, and an undocumented binary database. The app keeps its own selection instead and writes it into a playlist the iPod syncs. Before switching anything over I inventoried the device, which is how I found that the playlists I had ticked accounted for only 30% of what was on it — the rest came from individually ticked artists, and the obvious approach would have wiped it. Read about the iTunes remote → How it works →

The library that pipeline feeds didn't come from nowhere. It's about 95,700 tracks and it's three separate collections merged into one: my dad's, my brother's, and mine. Plus a lot of stuff pulled off old iPods and drives that had died. The merging was done folder by folder, artist and album, deliberately without importing anyone else's database or ratings or play counts, because that would have replaced my library instead of adding to it.

Putting something that size together turns up problems you'd never notice one track at a time. There were 1,073 audio files sitting on disk with no library entry at all. Whole albums, missing from the database while the files were right there in the folder.

Finding those was harder than it sounds. The library's XML escapes ampersands, stores paths in a different unicode normalisation than the filesystem gives you, and isn't consistent about capitalisation in folder names. Each of those threw up hundreds of false positives before it got handled, and one of them would have created real duplicates if I'd trusted the first answer.

I also built a 500 track "best of 2007 to 2011" playlist. About 33 hours, put together as 25 full album blocks and then 200 singles. The interesting problem there was that there's no listening history anywhere in the library, so popularity had to come from an outside ranking. And ranking by the year tag alone is a trap, because remasters and live albums and vinyl reissues all carry the reissue date. The first pass confidently suggested Bohemian Rhapsody and Highway to Hell as hits of 2009.

A pile of unlabelled external drives, gone through one at a time to find out what was on them. This started as a hunt for old iOS app files and turned into something closer to archaeology.

What they turned out to be: a 500 GB drive with fifteen partitions, no recognisable filesystems and sizes that were all powers of two. That one's a PlayStation 4 drive, encrypted against a console motherboard that doesn't exist anymore, so it's permanently unreadable. Then a High Sierra system drive with no apps on it but a 53 GB photo library going back to 1980. A nearly empty Windows partition. And a 750 GB FileVault drive that kept falling off the USB bus and is still sitting there unopened.

Then one 160 GB drive out of an old family PC had exactly what I was after. 49 iOS app files from the right era, every one checked as compatible with the device I wanted them on. Plus about 19,000 photos and videos, which are now in one album instead of scattered across drives nobody could read.

The reason for the app hunt. An iPod touch 4 running iOS 6.1.6, jailbroken so it can install software Apple stopped signing more than a decade ago.

Same idea with an iPhone 4S, going from iOS 9 back down to 6.1.3, which is a version Apple still signs. That's what makes it recoverable if it goes wrong. This one is genuinely hard: the downgrade needs a specific low level mode you can only reach from a jailbroken phone, so you have to jailbreak the exact version you're trying to get off. Still not finished.

And an iPad I was completely sure was an iPad 2. It's an iPad 3, and that difference decides everything, because the thing that makes the 4S recoverable doesn't exist for the iPad 3. Apple never shipped the release it would need in a form you can still install. Being told that before I spent an evening on it was worth more than any code.

Make it look at your actual setup before it writes anything. Every project here had at least one assumption that was wrong at the start, and finding those first is a lot cheaper than debugging them later.

Ask it to test the things that go wrong, not the thing that goes right. The vinyl pipeline is only worth trusting because we killed a transfer halfway through and watched what happened.

And read what comes out. Two of the bugs in the vinyl project were in code that looked completely reasonable and did the opposite of what it said. Writing the code turns out to be the fast part. Knowing what to check is where the actual work is.