My dad has been asking the same question for months: "How can we listen to ad-free radio in the kitchen without upsetting your mother?"

The radio station in question has an app and is available on smart speakers but the kitchen is a sacred space for my mother. The only technology allowed is a 10 year old Denon Hi-Fi system and a landline telephone.

What I find amazing is they actively want to give this service their money and technology is making things harder. The irony wasn't lost on me.

I'm a designer. I work in tech. I should be able to build a device that can do this, right?

Vision

Plug in the device → Radio starts playing

It really needs to be that simple. That level of simplicity is, in fact, incredibly difficult to achieve.

Thinking like a designer

Who's the audience, what are they familiar with, what feedback do they need when there's no interface? What happens when wifi drops, or the stream fails, or their subscription expires? These are types of experiential risks I consider all the time at work.

My approach

There will be no visual interface so everything needs to happen automatically, invisibly, and only make a sound when it’s really important.

Boot sound —Acknowledge that the device is on (there are also some LEDs as visual indicators). Unfortunately there is no way to create a true boot sound and nor is there an onboard speaker so playing this after 20 seconds will have to do.

Status messages — Spoken messages (rather than sounds) that loop every 30 seconds that include instructions on how to 'fix' the issue "Turn it off and on again". I used ElevenLabs to generate messages in an approachable British accent.

Auto-connect — I know their Wi-Fi name and password so I created a dummy Wi-FI network to test. This should allow the device to connect automatically when it arrives.

This can't be a unique problem

What about actually streaming the radio? I can't be the only one to face this issue, or a version of it. I subscribed to the station and ordered a Raspberry Pi, then searched for ways to stream radio on it.

I found a few music servers but only Lyrion Music Server was mature enough and had plugins that support the station I needed. Install it, add the plugin, log-in, click play and DONE. Almost. It was unstable, and difficult to automate.

I spent hours working through the documentation, building watchdog services to monitor and restart the audio. And every morning it was dead. Checking the logs gave no specific errors.

Troubleshooting for my parents needs to be no more complicated than "unplug it and plug it back in". This was not going to work. Back to the drawing board.

The solution

I was overthinking things. If a third-party plugin could stream this app-only radio station then surely I could as well. I instructed Claude Code to inspect the plugin and the stream URL (from the first-party app) and reverse engineer a way for me to get direct access. We discovered the URL does not contain API keys or be obfuscated in any way; it simply contains the user ID of the paying user (so it does some internal check before playing).

This means if I could get the user ID, I could use the stream directly and drop Lyrion entirely. This solved 95% of my problems and the stream ran for days while I was working through other parts of the experience.

With the hardware issues sorted I needed to work on how I would explain, even to my father, how to put it all together.

A quick-start guide

I designed and printed a card to sit just inside the lid of an Apple TV box that I'm shipping everything in. My dad will set it up and he's more tech-savvy. This was just a bit of fun.

Great! Now they know to plug in the antenna first, where to plug in the cables, and what to do before turning on the device (so they can hear the personal message I've recorded for when the device is warming up).

Packaging

Why stop at a quick-start guide? Let's cover up the fact that it's an Apple TV box. After all I don't want them to think I've bought them an actual Apple TV; that's the last thing they want.

I had some fun copying the technical details from the side of the Apple TV. I don't know if they'll read it but it was fun and tongue-in-cheek.

The finished product

The always-on, zero-setup, plug-and-play Premium Radio Streaming Box.

The reveal

Christmas morning, I watched the video call as my dad unwrapped the box. "Oh, that's great," he said, genuinely pleased. "Where did you find that?"

Find it. Not make it.

For a moment I considered explaining the week I'd spent debugging Lyrion, the hours on the self-healing uptime monitoring, CLI tooling, the ElevenLabs voice generation, the tongue-in-cheek packaging I'd laboured over (maybe one day I will) but right then I simply replied: "I made it".

We hung up. He went to set it up.

A few minutes later my phone buzzed with an Uptime Kuma alert: Device online. I opened my laptop, SSH'd in through Tailscale and ran a status check:

System uptime: 7 minutes  
Stream status: Playing
Playback duration: 6:30

It worked.

My parents experienced it as magic. Plug it in, radio plays. I experienced it as a well-designed system. Monitoring dashboards, remote SSH access, automated logging.

Two completely different experiences of the same product.

The CLI I'd carefully designed? The watchdog service? The backup documentation? None of that exists in my parents' mental model. For them, it's just a box that plays radio that they'll never think about. To them, "AUX" on the Denon Hi-Fi now means 'ad free radio'.

I did my job so well that they assumed someone else made it.

Designing my experience

I knew I was going to be administrating this and fixing anything that I couldn't account for; but how can I do that from 2500km away? And how can I make my experience less painful and maybe even enjoyable?

The UX of a command line utility

As I used the terminal more I realised that it, too, requires the same care and attention as any other interface. How can I make this intuitive, predictable, and usable. I found a great resource https://clig.dev/ which has a wealth of HCI guidance for terminal output.

Access — I can use Tailscale to ssh into the Pi as if it were at my desk.

Monitoring — I already use Uptime Kuma on my homelab so I can add a monitor for the Tailscale IP of the device and detect basic connectivity issues and when it's powered on for the first time.

Logging — I added detailed logging to track down issues and get a radio 'uptime' percentage. I want over 95% because this is a set and forget, always-on device.

Watchdog — I need something that actively monitors internet connectivity, audio output, memory usage etc. and can restart services or the whole device automatically if necessary.

Backup — I want to be able to back up all relevant files that I change. I also want to include included a restore document for file locations and commands to run after.

Readme — I don't know when the next time I will need to do any work on this machine. I will forget what I've done, why, and where. Keeping a README.md file on disk means I'll be able to get up to speed quickly. It should also be backed up.