What Building dAudio Taught Me About the Real Cost of Vibe Coding

dAudio is an Android media player. A very simple one. It plays audio, and it does nothing else. That restraint is the whole point — and getting to it, working alongside an AI, turned out to be more instructive than the build itself.

The silly little problem

I drive a Ranger, and I do school runs. Those runs stretch my working day, but they hand me a quiet window mid-afternoon — sitting in the sought-after parking spot I had to claim a full forty minutes before the gates open.

There's a small Android device plugged into the ute. It streams video when I'm parked, but most of the time it's playing the MP3s off a TF card. That's its real job. And playing those MP3s has been a genuinely annoying experience.

The default media player was horrendous. Every alternative I tried — including a paid product I won't name — was simply too fiddly to use while driving. I have a decent-sized screen, and it was still far too easy to fat-finger the wrong control and land somewhere I couldn't get out of without giving the screen more attention than any driver should. My phone wasn't any better: the player I'd persevered with for years is ad-driven, cluttered, and somehow still misses half the music actually on the device.

So I decided to build my own.

Deciding what to leave out

The interesting design work in a minimal app isn't what you put in — it's what you have the discipline to leave out. Two things went on the "no" list immediately.

Equaliser controls. Android already handles my audio system-wide, and the Ranger has perfectly good equalisation built into its own controls. Yes, that makes dAudio less of an all-in-one — but most people set that kind of thing up once and never touch it again. Every feature I add makes the app harder to build, larger to ship, and more likely to duplicate something the OEM or another app is already doing with the same audio pipeline. Wasted effort, in other words.

Fancy visuals. I'll use album art when it's there, but beyond that, less is more. You're not supposed to be looking at the screen. If you are, all that should be on it is the handful of things you — or the co-pilot — actually need.

The interesting design work in a minimal app isn't what you put in. It's what you have the discipline to leave out.

Why I gave the whole thing to Claude

I could have used one of my own local LLMs for this, but the project had all the makings of something that would outgrow the context a local model can hold, and I wanted it done quickly. So I handed the whole build to Claude Code, working directly on my machine where I could test in real time against a mix of real devices and emulators.

That did not make it happen in seconds. It was still about a day's work on my end. Enormously faster than coding it by hand — but the initial prompt describing what I wanted and how I wanted it built was only the starting gun. What followed over the next several hours was far more evolutionary than that word "prompt" suggests.

Scope creep, in reverse

Claude latched on quickly to the fact that the device in my Ranger is a media player I can't easily sideload onto for testing. That pushed us to narrow the scope: rather than chase every possible in-car setup, we'd focus on building a clean Android media player and testing it in an Android Auto context.

"Android Auto" is a deceptively broad target. The device in my Ranger loads its own Android interface, and then Android Auto tries to take over and use my phone instead. I prefer the device, because that's where the music lives — so technically it isn't really an Android Auto implementation at all. But if that TF card ever dies, the copy of my music on my phone is a handy backup.

Other vehicles I've owned behaved differently again — some limited "Android Auto" to a couple of apps and defaulted to pushing music over Bluetooth through their own player. There are too many scenarios to cover cleanly, so the scope settled where it should have: a minimalist Android app, tested against Android Auto, useful to anyone who just wants a simple player on their device.

Where the AI and I disagreed

This was the genuinely interesting part, and it's the bit most "I built an app with AI" stories skip.

Claude fixed hard onto the safety dimension of an in-car media player and would not let it go. That instinct is correct, up to a point — but it started to get in the way as we passed milestones. The turning point was album navigation. When you open an album list, tap into an album, and expect to see its tracks, that's simply how a human behaves. It's an ingrained expectation.

From a pure safety-optimisation view, you can see why a machine might resist: drilling into a track list is attention-diverting, so why not discourage it? But that misses something important about people. A human expects to do this, and will try to do it regardless. If the app doesn't behave the way they expect, they don't give up — they fight it, and that struggle is a far bigger distraction than just letting the feature work as anticipated. It took some pushback to land that point. And in any case, dAudio isn't only for cars — plenty of people just want a straightforward player on their phone.

We had a similar conversation about search. Claude was hesitant at first, but the moment I explained that voice search is something users simply expect from a modern player, it plumbed the feature in quickly and well.

The AI optimised for safety. I had to advocate for how humans actually behave. That tension — not the code — was the real work.

Vibe coded, but not hands-off

To use the modern parlance, dAudio is indeed fully "vibe coded." But that label undersells the human input. The AI did the heavy lifting on the code, and without it this project simply would not exist — not because I couldn't write it, but because I could never justify the time to build the same thing by hand. What it didn't do was make the product decisions, catch the human-behaviour gaps, or test the thing on real hardware. That was all me.

There's roughly ten hours of development between that first prompt and the version now sitting on my phone. As a phone MP3 player, I'm happy with it. Next it goes into the car for testing in an Android Auto context, then onto a few other Android devices I have floating around. After that comes Google's Play Console gauntlet: twelve testers running it for fourteen days before I'm even allowed to apply for a production release.

The honest arithmetic

Here's the part worth being straight about, because the hobbyist maths and the professional maths are very different animals.

A hobbyist at home might look at "a couple of thousand installs at a couple of dollars each" and see dollar signs. But I'm an IT professional, and when I'm not, I'm a father and a husband. My time in front of a computer needs to be productive — whether for my employer or my own businesses. It needs to generate income.

Those ten hours from first prompt to working build weren't free time. They were professional development hours invested in an idea that, at realistic app-store pricing of a few dollars, might reach break-even somewhere around the first 500 paid installs. And I've got at least as many testing hours still ahead, plus the two-week, twelve-tester Play Console requirement before it can go live. Add all that up and a single small app suddenly needs a few thousand paid installs just to justify its own cost.

So why build it? Because the problem annoyed me enough to be worth solving, because I'll use it every single day, and because a real project — shipped end to end — is the most honest demonstration there is of what AI-assisted development can and can't do. The code was the cheap part. The judgement around it wasn't. That's the lesson I'll carry into the next one.