§ 01 · What we builtA Goodreads for podcasts, except you never have to log a thing.
Adam Kruger wanted a Goodreads for podcasts, somewhere to see what he, his friends, and his coworkers are actually listening to. So he worked with Claude to find a way in to backend of a podcast app, and built a tracker that syncs itself every 12 hours.
Adam Podcast History app is a small personal site that keeps a running history of every podcast episode Adam finishes. He doesn't have to add anything by hand. A job runs every 12 hours, reads his listening activity straight from his podcast app, and writes each new episode into the history. He can go back and add a rating, or a note about what he learned or why he hit play in the first place.
The entire stack is free with the exception of Claude code which needs a Pro account from Anthropic. The code lives in GitHub, it's hosted on Vercel, and it was built with Claude Code, specifically the Sonnet model. No custom domain yet, no paid backend, no cost to stand it up. Open his page right now and the receipts are all there: 59 episodes across 21 shows, 2.4 days of total listening, and a concerning average 2.1x playback speed.
§ 02 · Build processFrom a one-line ask to a self-syncing tracker.
Adam started in Claude Code with a plain ask: he wanted a Goodreads or Letterboxd for podcasts, and ideally it would sync on its own. He didn't know which app could make that possible, so he didn't guess — he had Claude research what was available. The answer came back: Pocket Casts, the one mainstream podcast app that exposes an API you can pull your listening data out of.
From there Claude wired up the plumbing. Adam gave it access to his Pocket Casts account, and it set up a job that pulls his latest activity every 12 hours and writes each new episode into the history. He'd been on a different podcast app before this, so he asked Claude whether switching would be a pain. It wasn't — he exported a file of all his subscriptions from the old app and imported them into Pocket Casts in a couple of steps.
Then he iterated. He wanted to rate an episode and jot a note about what he learned or why he listened, so he went back to Claude and had it add those fields. 80 to 90% of what you can see live on the app landed in the first one to three prompts, but the total project took around 37 deployments.
§ 03 · Problem being solvedBooks have Goodreads. Movies have Letterboxd. Podcasts have nothing.
This idea had been sitting in Adam's head for a year or two. He'd been on Goodreads for a while and then he found Letterboxd, the same idea for movies. But for podcasts, the thing he's consuming more and more of, there was nothing popular to point at.
He's genuinely curious what his friends and coworkers are listening to, and he figures a few people might want to see what's on his feed too. The catch with Goodreads and Letterboxd is that you have to remember to log things. You finish a book, you go add it. You watch a movie, you go add it. Adam wanted the version where he never has to remember, the app just knows.
§ 04 · What was the hardest partThe part that was actually new: talking to an API.
Pulling data out of Pocket Casts meant working with an API (Application Programming Interface), and that was the genuinely new layer for Adam. A year ago he had no comfort with APIs at all. He's picked some up since, partly at work and partly from Claude Code, but he still wouldn't call himself experienced. This was the first project where he went a layer deeper on one.
His journey through this part of the prompting exercise is worth noting. When Claude presented something he didn't understand, he didn't just go along and hit auto accept and pray for a good outcome.
If Claude says something I don't follow, I just tell it: explain it to me like I'm five. Most of the time it does a genuinely good job.
— Adam Kruger
§ 05 · What went wrongIt only works if you switch apps, and nobody switches apps.
The whole auto-sync hinges on Pocket Casts being the one mainstream app Claude recommended could achieve the data sync. Adam looked — he couldn't find a way to do it with Apple Podcasts or Spotify or any of the bigger players.
This struck me as odd since I was convinced that companies the size of Apple and Spotify would have these API endpoints available. So I took Adam's advice and just asked Claude about the state of these two products' endpoints.
That turned out to be a blocker, both Apple and Spotify don't support a recently played podcast endpoint.
For a consumer facing application this could present a real wall. As Adam put it, asking people to move their entire listening habit to a specific app is going to hurt adoption. Most people simply won't. There's a manual version that would work anywhere — search the episode, add it, Letterboxd-style — but then you're back to the chore he was trying to overcome.
§ 06 · What you learnedThree things learned from someone on their fifteenth side project.
One: the learning curve flattens fast. The first project Adam built was the big learning curve. What did it mean to host an app, how do you get something to appear on the internet instead of just at localhost:3000, what even is GitHub. By the time he got to this one, all of that was muscle memory, and the only genuinely new thing left was going a layer deeper on an API.
Two: The most expensive model isn't the only answer. Adam's building ramped up over the December holidays, right after Opus 4.6 came out and everyone called it a game changer. He'd used Opus for basically everything, at work and at home, until this project — where he tried Sonnet instead and it held up fine for the job. The main reason for this switch was usage, Opus eats up tokens much quicker so model management is key to staying within your hourly usage limits
Three: when in doubt, make Claude explain it again (explain this to me like im 10, and I have no idea what any of this means). One great aspect about AI is that its not judgemental, you dont need to pretend to be an expert, you can be free to ask when you don't know. Just mind your token usage!
