I got the idea from a recent Hard Fork episode about “vibe coding.” Everyone seems to be using AI to build software by describing what you want rather than writing code yourself–something beyond my current skill set, until now. 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 whether 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 and integration with multiple data sources. When I managed a mobile app team at Consumer Reports, a minimum viable product like this would have been at least one sprint or a couple weeks of work. Here it was a few hours of me talking to Claude Code, and I had fun doing it. All of a sudden the gap between what I had envisioned and reality was passable.

I named it “Great Reads Now!” and it does one thing well: shows me great 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 but I found the number of options overwhelming, so three it was.

But what if I wanted something more personal? 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 yet — a conversation instead of a long list of thousands of available titles which may or may not be to my liking.

I also added print book availability and a ThriftBooks search for when I’d rather own it and 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: github.com/ted-bongiovanni/npr-bpl-checker

What it cost

I’ve led software teams that build 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 a Claude account and $5 in API credits for the chat interface.

The value is in knowing what to build and why. That said, you might have to go through the process of making it to realize if it’s worth the effort. For me, this was more of a learning project–what can I do with my imagination and these new tools?

The app works because I had identified a real, if minor pain point. Because I’d lived with the Libby frustration for years, I had a good sense of which features mattered (the “show me three” randomizer) and which were noise (I thought Goodreads ratings would be handy, but they cluster so tightly they’re useless for decisions — I made them a toggle, a feature I’ll likely deprecate).

What this isn’t

It’s not production software. My API (Application Programming Interface) key is probably in the wrong place. The data refresh is manual. 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 it: 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.

Update: Since writing this post, I shipped a second app — Bike Crash Log, a personal tool for bike commuters to track rides, report crashes, and log safety conditions. Different problem, same process: a real frustration, a conversation with an AI, and a working tool by the end of the day. And I had fun doing it.