Daniel's been thinking about a device that doesn't exist. He's searched for it, come up empty, and now he's wondering why. The idea came out of spending long hours in underground shelters during the war with Iran — unreliable internet, lots of time, and a craving for something specific. He wanted a device shaped like a traditional radio, with a built-in speaker and a screen, whose only job was to play podcast subscriptions. But here's the part that makes it interesting: it needed to download episodes for offline listening. Not stream. Download. And when he went looking for this thing — an internet radio that can cache podcasts locally — he found nothing. Internet radios exist. Podcast apps exist. The combination does not. So he's asking us two things. First, why is there a gap in the market for a dedicated podcast player with offline download? And second, if he brings the idea but doesn't want to build the hardware himself, are there alternative paths — open-sourcing the design, crowdsourcing production, finding a partner — that could actually bring this thing into the world?
The gap is real. I spent an afternoon checking this, and Daniel's right — Grace Digital, Sangean, Ocean Digital, all the major internet radio manufacturers, none of them offer offline episode caching. You can stream podcasts on some of their devices if the station has a podcast feed, but the moment you walk out of Wi-Fi range, it's a brick for that use case. I pulled up the manual for the Grace Digital Mondo and the Sangean WFR-32. Both of them have USB ports. Both of them can play MP3s off a thumb drive. So the file system is there, the decoder is there, the storage controller is there. They just don't connect any of that to the internet radio side of the device. It's two separate modes that never touch. And the thing is, the hardware is theoretically capable. The chipsets in most of these radios have storage controllers. They just don't use them for this.
So the question isn't whether it can be built. It's why nobody's built it. The USB port proves the hardware knows how to read files. It just doesn't know how to download them.
And I think the answer splits into two parts. One is about how we relate to devices — why a single-purpose thing feels different from a phone. The other is about markets and incentives, and why the people who could build this haven't bothered.
Let's start with the first part. Daniel mentioned something in his prompt that I think is the real engine here. He said he finds it easier to read long text on a tablet than on a laptop because it's harder to multitask. That's not a trivial observation. That's a theory of attention. He's saying the device itself trains you to use it a certain way. A laptop screen invites you to have seventeen tabs open. A tablet, especially in a reading mode, says no — you're here for this one thing. And he wants that same constraint for listening.
It is. I've been calling this the container theory of device design. A phone is a portal to everything — your messages, your email, your social media, your browser, your games. Every notification is a little hook pulling you out of whatever you were doing. A single-purpose device has no hooks. It does one thing. The friction of switching tasks is enormous because switching tasks means putting the device down and picking up a different one. So you stay in the experience. Think about a Kindle versus reading on your phone. On a phone, reading is one swipe away from Instagram. On a Kindle, reading is the only thing the device knows how to do. You'd have to physically put it down and reach for something else to break the spell. That's the container.
The Hörbert device is the cleanest example of this. It's a wooden box with a crank wheel, an SD card slot, and no screen. Designed for children. You load MP3s onto an SD card, put it in, and the child navigates with physical controls. No browser, no app store, no notifications. The limitation is the feature. And what's interesting is that adults buy them too. There's a whole cohort of grown-ups who want exactly this — a device that enforces intentional listening by removing every other option. I read a forum thread where someone described using their kid's Hörbert to listen to audiobooks while doing woodworking. They said, and I'm quoting, "My phone would have me checking email by chapter three. This thing just plays the book."
And that's the thing. Daniel's instinct about the radio form factor isn't nostalgia. It's about creating a container. A dedicated podcast player with a speaker and a screen says, this is for listening to podcasts. Nothing else. You pick it up and you know what you're doing. A phone says, here are eighty-seven things you could be doing right now, good luck staying focused on the one you intended. The radio form factor also brings something else — it's a shared listening device. A phone is inherently personal. You put in earbuds and you're in your own world. A radio with a speaker fills a room. You can listen while making breakfast with someone else in the kitchen. It changes the social dimension of the experience.
A podcast on a phone is a solitary experience. A podcast on a kitchen radio is something you share, even if nobody's actively listening. It becomes part of the atmosphere of the house.
Right. So the desire is real, and it's not just Daniel. The question is why the specific combination — internet radio plus offline download — doesn't exist. And I think this is where we get into the technical piece.
Before we go there, can we talk about why offline matters so much? Daniel mentioned unreliable internet in the shelters, but that's an extreme case. Why does offline matter for someone in a regular apartment with stable Wi-Fi?
Two reasons. One is practical — not everyone has good internet all the time. People in rural areas, people who commute through tunnels, people who travel. But the bigger reason is psychological. When you know a device can only play what it's already downloaded, you engage with it differently. You're not browsing an infinite feed. You're choosing from a finite, curated set of episodes you intentionally saved. It's the difference between a library and the open web. A library has walls. The walls are the point.
So the download isn't just a technical feature. It's part of the container. It enforces curation.
Now, let's walk through what a device like this actually needs to do. A podcast app on your phone manages a dynamic feed. Episodes appear, episodes disappear, feeds update, some shows change their feed URL. The app has to sync feed state, track which episodes you've played and which you haven't, handle storage limits, and manage deletion policies. Do you keep the last three episodes of every show? Do you delete anything older than thirty days? What happens when a show publishes a corrected version of an episode? None of this is hard in the sense of being unsolved — every podcast app does it. But it's software complexity that internet radio manufacturers have never had to deal with.
Because their devices stream. A stream is ephemeral. You connect, you play, you disconnect, there's nothing to manage. The device doesn't need to remember what you listened to yesterday because yesterday's stream is gone.
An internet radio is essentially a browser that can only visit audio streams. Adding offline download turns it into a stateful device. It has to remember things. It has to make decisions about what to keep and what to discard. And the user interface has to expose those decisions in a way that doesn't feel like managing a file system. You can't just show a folder tree. That's a nightmare on a small screen with a knob. You need something more like a podcast app interface — show art, episode titles, subscribe and unsubscribe, play status — but on hardware that was designed to tune to a frequency and adjust volume.
Which is where most hardware companies nope out. The UI complexity alone is a product manager's nightmare. You're taking a device with maybe six buttons and a two-line LCD and asking it to behave like a smartphone app. The interaction design problem is hard. How do you search for a podcast by name using a scroll wheel? How do you browse a feed with hundreds of episodes?
Right. And then there's the demographic reality. Internet radio manufacturers target an older audience. The average buyer is in their sixties or seventies, and they're buying a device to listen to BBC Radio 4 or classical stations or talk radio from their home country. They are not downloading podcast episodes. The feature request literally doesn't reach the roadmap because the customers aren't asking for it. I looked at the marketing materials for the top five internet radios on Amazon. Every single one emphasizes "easy setup" and "no computer required." The value proposition is simplicity. Adding podcast management destroys that.
So it's not a technical impossibility. It's a market assumption that's never been challenged. The manufacturers have decided their customers don't want this, and they've never tested whether a different set of customers might.
And it's worth saying explicitly: DRM is not the issue here. Podcasts are open RSS. There's no licensing barrier, no encryption to negotiate. The barrier is purely software complexity and user experience design. If a manufacturer wanted to add offline download tomorrow, there's nothing legal stopping them. Compare that to trying to build a device that downloads Netflix shows for offline viewing — you'd need a licensing agreement, DRM keys, a whole legal department. Podcasts are the easiest possible content type to work with, and still nobody's done it.
That's almost more frustrating, isn't it? The thing could exist. The parts are all there. Nobody's assembled them. It's like having all the ingredients for a meal on the counter and just... not cooking.
And the Atonemo NTS Radio Player is the perfect illustration of how close we are. Beautiful hardware. Dedicated device. Physical controls. But it's streaming-only. It's a radio, not a podcast player. The gap Daniel identified is exactly the distance between that device and the one he wants — add offline storage, add feed management, and you're there. But nobody's crossed that line. The Atonemo people clearly care about design and the physical experience of audio. They're so close. But they stopped at streaming.
It makes you wonder if they even considered podcasts. Or if, like the rest of the industry, they just didn't see the use case.
So the technical barriers are real but solvable. The harder question is what you do about it if you're not going to start a hardware company.
And this is where the market reality gets brutal. Internet radio is already a shrinking category. Most people stream on smart speakers or phones. Adding podcast download targets an even smaller subset — people who want a dedicated device and listen to podcasts offline. The economics for a traditional hardware startup are terrible. Tooling costs, minimum order quantities, certification — FCC, CE — inventory risk. You'd need to sell thousands of units at a healthy margin just to break even, and the addressable market might be in the hundreds.
Let me put some numbers on that. Injection molding for a custom enclosure — a single mold can cost ten to twenty thousand dollars. FCC certification is another ten to fifteen. CE marking for Europe, similar. If you're doing a run of a thousand units, you're looking at maybe a hundred and fifty to two hundred dollars per unit just in upfront costs, before you've bought a single component. And you're selling to a market that might be five hundred people total. The math doesn't work.
So a venture-backed startup is not the path. What else is there?
Three paths, I think. The first is open-sourcing the design. Daniel could create a detailed specification and reference design — Raspberry Pi, DAC hat, small screen, battery, enclosure CAD files — and publish it on GitHub or Hackaday. The community forks it, improves it, builds their own. We've seen this work. The MNT Reform laptop is an open-source design that people actually buy and build. The Novena laptop before that. Olimex has an entire ecosystem of open-source hardware. But these are built by enthusiasts for enthusiasts. Someone still has to create the initial design and write the documentation.
And Daniel said he'd rather do almost anything else than build it himself. So the open-source path still requires a builder. It just doesn't have to be him alone. He could be the project manager, the spec writer, the person who rallies the community. But someone has to write the first lines of code and design the first PCB.
Right. Which brings us to path two: crowdsourcing the development and production. There's a platform called Crowd Supply that specializes in open-source hardware. They've funded projects like the MNT Pocket Reform and the Fomu FPGA. The model is different from Kickstarter — they're focused on engineering-heavy projects with smaller audiences. And here's the interesting part: if you pitch the product as a kit rather than a finished device, the regulatory barriers drop significantly. Kits are exempt from FCC certification in the US. You're selling a PCB, an enclosure, and firmware that the buyer assembles. That reduces inventory risk and upfront cost.
So you're not selling a product. You're selling a project. Here's a box of parts, here's a guide, you build it. And the buyer accepts that it might be a little rough around the edges because they're part of the creation process.
For a niche this small, that might be the only viable model. A few hundred people who want this thing badly enough to spend a Saturday with a screwdriver and a soldering iron. The economics work at that scale. They don't work at the scale of a Best Buy shelf. I've backed a few Crowd Supply projects, and the vibe is completely different from a consumer product. The updates are like, "We found a bug in the power management circuit, here's the workaround." And the backers are fine with it because they're in it for the journey as much as the destination.
The third path is finding a partner. Daniel could approach Grace Digital or Sangean or Ocean Digital directly with the feature request. If enough people email them, it might show up on a roadmap. Or approach podcast app developers — Pocket Casts, Overcast — about a hardware partnership. That's less likely, but not impossible. Companies do weird niche things when a founder gets excited about an idea. Remember when Panic, a software company, made a handheld gaming device? Nobody saw that coming.
The Playdate. Right. And that's a good example of a small company doing something weird because the founders wanted it to exist. But Panic had money from their software business to fund the hardware development. Most podcast app developers are running on thin margins. They're not sitting on a war chest for hardware experiments.
The collective approach is maybe the most interesting. A community-run podcast player. The hardware is the easy part — off-the-shelf single-board computers, DACs, screens, batteries. The software is the ongoing maintenance burden. A Linux-based firmware that handles RSS feed management, syncs with podcast indexes like Podcast Index or Apple Podcasts, and runs on commodity hardware. The real question is whether the community would sustain the software updates for years. Podcast feed formats change. APIs break. Security patches are needed. Open-source projects die all the time because the maintainer burns out.
It's not just the maintainer burning out. It's that podcast feeds are surprisingly messy in the real world. I've done some work with RSS parsing, and every feed has its own quirks. One show uses a non-standard namespace for chapter markers. Another has cover art in a weird resolution that breaks your layout. Another changes their feed URL every six months and expects clients to follow redirects. A dedicated device has to handle all of that gracefully, and the edge cases never stop coming. That's the kind of thing that wears down a volunteer maintainer.
That's the unglamorous part of this. The hardware is a one-time problem. The software is forever. You ship the box and you're done. The firmware is a living thing that needs feeding.
It's worth noting that Podcast Index exists specifically for this kind of thing. It's an open, independent directory of podcasts, not controlled by Apple or Spotify. A community-driven firmware could use it for feed discovery without depending on any corporate API. That's the right building block. You don't want to build a device that depends on Apple's podcast directory staying free and open forever. Podcast Index gives you independence.
We've got three paths, none of them easy, all of them possible. But I want to go back to something. Daniel said he doesn't think this has commercial potential, and I think he's right. But I also think that's not the point. The point is that a few hundred people want this thing, and right now they have no way to get it. The question isn't whether it's a good business. The question is whether it's a good project. And those are different questions with different answers.
Projects have a way of finding their people. The Hörbert device started as a father building something for his kids. Now it's a company. The MNT Reform started as a frustration with closed hardware. Now it's a product line. These things don't start with market sizing. They start with someone saying, I want this, and I bet other people do too. The market sizing comes later, if it comes at all.
The cultural barrier is the one Hilbert keeps coming back to. He worked in this industry. He was in the room when these decisions were made. I think we need to hear from him directly.
I want to hear this. Hilbert, you've been quiet, which usually means you're sitting on something good.
Hilbert: Frontier Silicon chipset. The D-L-S series. We used it in every white-label radio we shipped to European retailers in the late two-thousands. It had an SD card slot on the reference board. The slot was there because the chip supported MP3 playback from local storage — it was a leftover from a portable radio design they'd done earlier. We never used it. I sat in product meetings where someone would say, what if we let people save streams to the card? And the product manager — a man named Gerald who wore the same gray sweater every day — would say, our customers are sixty-five and listen to BBC Radio 4, they don't know what a podcast is. And that was the end of the conversation. Every time.
The hardware was already there. The SD slot was on the board. The traces were routed. The firmware had the driver loaded.
Hilbert: The hardware was there. The firmware was a custom Linux build. We had file system support. We had a storage controller. We had everything except the will to write the feature. Gerald wasn't wrong about the customers, by the way. He was right. The people buying our radios in 2008 did not listen to podcasts. But the capability was sitting there unused for years. Through three product generations. We kept shipping the same chipset with the same unused SD slot. At one point we even put a plastic cover over it so customers wouldn't ask what it was for.
The gap is cultural. The people who make internet radios don't listen to podcasts, and the people who make podcast apps don't make hardware. Two completely separate worlds that happen to use the same underlying technology.
Hilbert: Two industries, same building blocks, no overlap. The chipset manufacturers don't care because they sell to both sides. The radio manufacturers don't see the demand. The podcast developers don't want to deal with supply chains and injection molding. Everyone's standing on their side of the fence waiting for someone else to cross. And the fence is only three feet high.
The chipset is still in use. Frontier Silicon chips are in most current internet radios. The SD card slot might be gone from the production boards, but the storage controller is still on the die. A firmware update could theoretically add offline download to millions of existing devices. Devices that are sitting in people's kitchens right now.
Hilbert: Theoretically. Nobody's going to write it. Gerald retired. The company got bought by a larger firm that sells smart speakers now. The institutional knowledge is gone. The engineers who knew the firmware inside and out have moved on to other jobs. The build environment probably doesn't even compile anymore. You'd need to resurrect a fifteen-year-old toolchain just to start.
The barrier was never technical. It was a product manager in a gray sweater who didn't believe the market existed. One person, in one meeting, making a reasonable call for 2008, and that call echoed forward for fifteen years.
Hilbert: He was probably right about the market in 2008. He'd be wrong now. Podcast listenership has exploded. But the companies that could act on that are either out of business or pivoted to something else. It's a ghost town. The factories are still there. The supply chains are still there. But the product teams that could say "what if we added podcast support" don't exist anymore.
That's almost worse. The moment has arrived, but the industry that could serve it has already moved on. It's like showing up to a party after everyone's gone home, and the music is still playing, but there's nobody there to dance.
Hilbert: I still have one of the prototype units in a box somewhere. The one with the SD slot wired up and actually functional. It worked. You could load MP3s onto a card and play them. It just never shipped. I kept it as a souvenir.
Of course you do. You've been sitting on the answer to Daniel's question this whole time.
Hilbert: The firmware was buggy. It would crash if the card had more than two hundred files. But the bones were there. Someone with time and a compiler could probably finish it. The file system code is written. The MP3 decoder works. It just needs the RSS feed handling and a UI layer on top.
That's the thing. The bones are still there. The hardware exists. The software is the missing piece, and software is the one thing a community can build without tooling costs or certification. You don't need a factory to write firmware. You need a few people who care enough to do the work.
We're back to the open-source firmware idea. But now it's not theoretical. The chipset supports it. The reference design existed. Someone just has to write the code. And we know, from Hilbert's prototype, that the hardware path is proven.
Maintain it. That's the part that keeps me up. Open-source hardware projects have a half-life. The excitement carries them through the first release, and then the maintainer gets a new job or has a kid or just loses interest, and the project goes dormant. A dedicated podcast player needs ongoing updates — feed formats change, security patches, new podcast features. If the community isn't large enough to sustain multiple maintainers, it dies. I've seen this happen dozens of times. A promising project on Hackaday, a flurry of commits for six months, then silence. The repo sits untouched for years.
But that's true of every open-source project. The ones that survive are the ones where the maintainer is also a user. If Daniel wants this device badly enough, and a few hundred other people want it too, the maintenance burden gets shared. It's not one person burning out. It's a group of people who all rely on the thing working. They fix bugs because the bug is affecting their morning routine. That's a very different motivation than fixing bugs because users are complaining on a forum.
The nice thing about a dedicated device is that the scope is limited. It doesn't need to do everything. It needs to download podcast episodes and play them. That's a tractable software problem. You're not building an operating system. You're building an appliance. An appliance has a defined job. When the job is done, the software is done. You're not adding features forever. You're maintaining stability.
Which is actually the opposite of how most software development works. Most software is constantly expanding, adding features, growing in complexity. An appliance firmware should be shrinking over time — removing bugs, hardening the existing features, and then stopping.
The open question we want to leave Daniel with is this: is the gap real enough that a community would form around filling it? The hardware is solved. The software is a manageable project. The market won't support a traditional product, but it might support a kit or a reference design. The only thing missing is someone to write the first commit. Someone to say, here's a GitHub repo, here's a rough spec, who wants to help?
That someone doesn't have to be Daniel. He could write the specification, publish it, and see who shows up. Crowd Supply has a process for this — you can pitch a concept without having a prototype. If enough people pledge, you build it. If they don't, you know the gap was smaller than you thought. Either way, you get an answer. The uncertainty is the worst part, and this resolves it.
The cultural barrier Hilbert described is real, but it's also an opportunity. The big companies aren't going to fill this gap because they don't see it. They've moved on to smart speakers and voice assistants. That leaves it open for someone who does see it. Someone who wants the thing for themselves.
That's the best reason to build anything. Not because the market research says so. Because you want it on your kitchen counter.
Thanks to our producer Hilbert Flumingtop for the trip down memory lane and the confirmation that the hardware was capable all along. And for keeping that prototype. You should dig it out of the box sometime.
This has been My Weird Prompts. If you enjoyed this episode, rate and review us wherever you listen — and if you know someone who'd love a dedicated podcast player, send them this episode. Maybe one of them will write the first commit. We'll be back soon.
