The Death of the 'Perfect Tool'

When configuring someone else's tool takes longer than building your own, it's time to write the code.
2026-04-23

The Goal: A Pure Audio Experience

I've been on a bit of a self-hosting journey lately. As part of that, I dug up an old Raspberry Pi and added a DAC+ audio HAT to it, turning it into a dedicated audio streamer. There is something uniquely satisfying about reviving old hardware and giving it a single, focused purpose.

Naturally, the first thing it needed was a podcast player. I wanted something terminal-native, lightweight, and reliable. No bloated web interface, no Electron app, no setup wizard. Just a clean TUI where I could manage subscriptions and listen to episodes without ever leaving the shell.

The vision was simple. The execution was not.

The Rabbit Hole: The "Existing Tool" Trap

I started by doing what anyone does: looking for something that already exists. I found shellcaster, a Rust-based player that looked perfect on paper. Then the debugging began.

First, it wouldn't build because of a missing libsqlite3-dev dependency. Solved. Then a permissions wall trying to install to /usr/local. Solved. Then cargo not being in the root PATH. Also solved. After all of that, when I finally got it running, the app would claim to be streaming while mpv sat completely idle; no logs, no errors, just silence.

Frustrated, I switched to newsboat. It worked, mostly, until I noticed the p key moved the cursor instead of playing audio. I tried binding it, hit a version incompatibility (v2.21.0 doesn't support play as an action), and eventually settled for mapping p to open.

At some point I did the mental accounting, and realized that I had spent more time debugging other people's software and fighting their design decisions than I had spent actually listening to podcasts. The more interesting question surfaced: if the friction of configuring someone else's tool exceeds the friction of building my own, why am I still configuring?

The Pivot: If You Can't Find It, Build It

Using AI assistance, I built Podplayer in a single day.

The architecture is lean but purposeful. I wanted the app to feel like a real podcast manager, not just a script that fetches a URL. It needed to actually remember things.

Here's how it works:

Feed Parsing: feedparser handles the RSS side, navigating feeds and extracting episode metadata.
State Management: SQLAlchemy with a local SQLite database tracks subscriptions, marks episodes as listened, and stores your exact playback position for every episode. This is what separates Podplayer from a glorified shell script.
Playback Engine: python-mpv interfaces directly with mpv, giving the app broad format and streaming support without having to implement a media player from scratch.
TUI Layer: A custom interface that ties the database and player together into something that feels seamless to navigate.

What would have taken days of library evaluation, documentation archaeology, and boilerplate wrangling took one focused afternoon.

The AI Advantage: Removing the Hunt

This experience clarified something I'd been sensing for a while about how AI is changing personal projects.

The old barrier to "just building it yourself" was rarely a skill issue, it was the dwindling motivation over time. You'd spend three days choosing between RSS parsing libraries before writing a single line of code. You would lose an evening to a version mismatch then find a GitHub issue from 2019 that almost addressed your problem. AI has largely eliminated that layer of friction. The research is compressed. The boilerplate is handled. The hunt is shorter.

What that unlocks is a specific and underrated category of software: tools so niche they'll only ever be used by one person, and that's perfectly fine. Podplayer is exactly that. It was born from an old Raspberry Pi with an audio DAC HAT, but it runs fine on any terminal but the point isn't the hardware, it's that the tool is shaped precisely around how I want to interact with it, not around what some median user expects. Nobody else may ever need this exact thing. That's not a limitation, that's the point. The ability to write hyper-specific software for yourself, quickly, is genuinely new.

It also raises an uncomfortable question for software products more broadly: if a feature can be replicated in an afternoon, is it still a differentiator? Increasingly, the answer is no. The value in a tool is shifting away from what it does and toward how precisely it fits the person using it. Off-the-shelf software optimises for the median user. When you build for yourself, you are the only user, and the fit is, by definition, perfect.

Using Podplayer

If you want a lightweight, no-nonsense podcast setup that lives entirely in the terminal, Podplayer works on any machine that can run Python and mpv — headless Pi included.

Prerequisites: Make sure mpv is installed on your system.

# Debian/Ubuntu
sudo apt-get install -y mpv libmpv1

# macOS
brew install mpv

The quick way (uv):

git clone https://github.com/adityadhegde/fluffy-goggles.git
cd podplayer
uv run podplayer

The traditional way (pip):

git clone https://github.com/adityadhegde/fluffy-goggles.git
cd fluffy-goggles
python3 -m venv .venv
source .venv/bin/activate
pip install -e .
podplayer

Docker (Linux, with audio passthrough):

The docker-compose.yml mounts /dev/snd so the container can talk directly to your audio hardware:

docker compose build
docker compose run --rm podplayer

Once running, you can add feeds, sync episodes, and pick up exactly where you left off — playback position included.

Closing Thoughts

Podplayer is running on my Pi right now, doing exactly what I needed it to do. It's not a commercial product and it doesn't need to be. It's a tool built for a specific problem, on specific hardware, in a single day — and it works.

That turnaround is what's actually new here. The ideas behind Podplayer aren't novel. The speed at which a solo developer with a clear problem can execute them is. The combination of frustration and the right tools will always produce something; what's changed is how quickly that something becomes usable software.

The code is on GitHub: Podplayer