The App I Built Instead of Reading (That Now Helps Me Read)
Ted Bongiovanni Tips, Tricks Techniques, Leadership
I got the idea from a recent Hard Fork episode about "vibe coding"—using AI to build software by describing what you want rather than writing code yourself. But what to code? I have a love/hate relationship with Libby, the well-crafted app from Overdrive that lets you get e-Books from your local library.
My pain point: I'd browse NPR's "Books We Love" list, find something interesting, check to see if it's available at Brooklyn Public Library, discover it has a 12 to 24 week wait, add it to my hold list, and then weeks later when it finally arrived have no idea why I'd wanted it in the first place. The context was gone.
So I built an app to solve it. In a long afternoon, on a holiday. Without knowing how to code.
I mean, I've made some things, FileMaker databases to track community organizations back in the day, some DOS batch files, simple web pages and maybe a form here and there, a WordPress site. But nothing like this. This is a web app with filtering, a chat interface powered by Claude's API, and integration with multiple data sources. When I managed a mobile app team at Consumer Reports, an MVP (minimum viable product) like this would have been, I'm guessing, at least one “sprint,” or a couple weeks work. Here it was a few hours of me talking to Claude Code and I loved doing it. It was like I’d gotten software superpowers like Neo in the Matrix.
The tool is called "Great Reads Now!" and it does one thing well: shows me critically acclaimed books that are available right now at my library. No waiting, no forgetting why. It pulls titles from NPR's "Books We Love," the New York Times Best Books list, and AudioFile's best audiobooks. I can filter by genre, toggle between ebooks, audiobooks, and print, and hit "Spin Again" to get three random picks. Initially I had it show everything–that was too much.
But what if I wanted something a bit more personal based on what I’d read? So I added a chat feature. I can tell it "I just finished something heavy, want something lighter" and it recommends from the available pool. That's an interaction Libby might have but doesn't—a conversation instead of a long list of thousands of titles that are available now.
After thinking a bit more, I also added print book availability and a ThriftBooks search for when I’d rather own it to scribble in the margins. When I showed a friend, a Python user who builds math problem sets for his classes, he asked for a copy. Said he'd actually use it. So with Claude code’s help it’s now on my very first GitHub repository: https://github.com/ted-bongiovanni/npr-bpl-checker
The philosophical part
I've led software teams that create apps. I know roughly what this would have cost: a UX person, a developer, a PM–three people, two weeks, real money in loaded labor costs, plus all the coordination overhead. I did it with $5 in API credits.
If I were a developer, I think I'd be both awed and terrified. The core of what many mid-level developers do, translate requirements into working code, just got insanely cheaper. The value that remains is knowing what to build and why.
The app works because I had a problem. I wanted to see if I could code something; I was scratching an itch. And because I'd lived with the Great reads/ Libby frustration for years, I had a good sense of what features mattered (the "show me three" randomizer) and which were noise (Goodreads ratings cluster so tightly they're useless for decisions—I made them a toggle so users can show or hide them–a feature I’ll likely deprecate in a future release).
What this isn't
It's not production software. My API key is probably in the wrong place. The data refresh is manual. The descriptions are sometimes too short. If I wanted to share it publicly, I'd need a backend, user accounts, rate limiting. The gap between "works for me" and "works for everyone" is real.
But for me and my geeky friends? It is real software. It runs. It solves a problem. And I understand the shape of it well enough to keep adding features.
The trap (and the escape)
I'll admit: I built an elaborate tool for finding books and then spent several days building more tools instead of reading. Classic builder's trap. I had 40 pages left in a novel about Taiwan that I'd started so I'd have context for where my daughter is studying abroad.
But I did finish it. And then I used the app to find my next read, one that was available immediately. I also started an audiobook about John Lewis that I wouldn't have discovered otherwise.
So the tool works. Now I just have to keep using it for its intended purpose: reading, not building.