Live data from Hacker News

Tell HN: 2 years building a kids audio app as a solo dev – lessons learned

news.ycombinator.com

1–10 of 84 posts

Tell HN: 2 years building a kids audio app as a solo dev – lessons learned

#1
Hi,

I started Muky in April 2024. Classic side project that got out of hand. We have two kids - the younger one is happy with the Toniebox, but our older one outgrew it. She started asking for specific songs, audiobooks that aren't available as figurines, and "the music from that movie."

We had an old iPad Mini lying around and already pay for Apple Music. Felt dumb to keep buying €17/$20 figurines for 30-45 minutes of content when we have 100 million songs.

Now at version 4.0 after ~20 updates. Some lessons:

On the hardware vs app tradeoff: Toniebox and Yoto are brilliant for little ones – tactile, simple, no screen needed. But they hit a wall once kids want more. And handing a 5-year-old Apple Music means infinite scrolling and "Dad, what's this song about?" Muky sits in between – full library access, but parents control what's visible.

On sharing: Remember lending CDs or cassettes to friends? Or kids swapping Tonie figurines at a playdate? I wanted that for a digital app. So I built QR code sharing. Scan, import, done. And unlike a physical thing – both keep a copy.

On onboarding: First versions: empty app, figure it out yourself. Retention was awful. Now: 4-step onboarding that actually guides you. Should've done this from the start.

On content discovery: 100 million songs sounds great until you have to find something. Parents don't want to search – they want suggestions. Spent a lot of time building a Browse tab with curated albums and audiobooks for kids. Finally feels like the app helps you instead of just waiting for input.

On going native: Went with Swift/SwiftUI instead of Flutter or React Native. No regrets - SwiftUI is a joy to work with and performance is great. Android users ask for a port regularly. No capacity for that now, but Swift for Android is progressing (https://www.swift.org/documentation/articles/swift-sdk-for-a...). Maybe one day. CarPlay is another one parents keep asking for – going native should make that easier to add, if Apple grants me the entitlement.

On subscriptions vs one-time: Started with one-time purchase. Revenue spikes at launch, then nothing. Switched to subscription – existing one-time buyers kept full access. Harder to sell, but sustainable.

Ask me anything about indie iOS dev or building for kids. App is at https://muky.app if you're curious.

Re: Tell HN: 2 years building a kids audio app as a solo dev – lessons learned

#2
Great niche!

Few questions: - Were you soloing the entire thing? What about ops/research/market analysis? What about the design?

- Did you think about it as product-first or technology-first? Other words, did you build a solution for scoped audio mgmt, or a music player for kids?

- What's your tests status? Full coverage? CI/CD?

- How did you approach the entire legal aspect? Single lawyer? Self? Not at all?

Re: Tell HN: 2 years building a kids audio app as a solo dev – lessons learned

#4

Can you explain a bit more on how this is better than just using Spotify? Is the catalogue restricted somehow?

Good question. Same catalog - Muky uses your Apple Music or Spotify subscription underneath.

The difference: Muky separates the audio player from the admin area. Kids get a locked-down player showing only playlists you created – big artwork, tap to play, nothing else. Parents manage everything in a separate admin area – create playlists, add content, adjust settings.

Spotify means infinite browsing, algorithm recommendations, and "Dad, how do I get back to my song?"

Plus with 4.0 there's a Browse tab with curated content for kids, so you don't have to search through millions of songs yourself.

Think of it as a "view" on top of your existing subscription. Parents curate in the admin area, kids see only what you want them to see.

Re: Tell HN: 2 years building a kids audio app as a solo dev – lessons learned

#6

Great niche! Few questions: - Were you soloing the entire thing? What about ops/research/market analysis? What about the design? - Did you think about it as product-first or technology-first? Other words, did you build a solution for scoped audio mgmt, or a music player for kids? - What's your tests status? Full coverage? CI/CD? - How did you approach the entire legal aspect? Single lawyer? Self? Not at all?

Thanks!

Solo? Yes, everything. Design, code, marketing, support. No team, no outsourcing. Last few months Claude Code has been a huge help for brainstorming, copywriting, and rubber-ducking code problems.

Product or tech first? Product first, 100%. Started with the problem: my kid needs access to more music, but I don't want to hand over Apple Music. Tech decisions followed from there. SwiftUI because I wanted native performance, Realm for offline, etc.

Tests/CI/CD? Honestly, test coverage is thin. I have unit tests for critical parts (subscription logic, playback state) but not full coverage. No CI/CD - just manual builds and upload to TestFlight. Good enough for a solo project.

Legal? Self, mostly. Apple's standard EULA covers the basics. The app doesn't collect anything.

Re: Tell HN: 2 years building a kids audio app as a solo dev – lessons learned

#8
I'm currently using Flutter for a project. Considering I've been lead author or co-author on a few Android programming books, using a cross platform SDK was new for me. Dart is easy to learn, and Flutter makes attractive UI easy. I love to work on a big ambitious projects that really need platform specific implementations, but for the vast majority of cases a good cross platform SDK works well, and is a cost-efficient approach.

Well, not entirely not entirely a new experience: I had to use Xamarin on Android once because the client wanted a unified code base their existing Windows coders could maintain. It was an appropriate choice for that project, which was a piece of industrial equipment. I would not use Xamarin for mass market or even widely deployed enterprise apps.

Re: Tell HN: 2 years building a kids audio app as a solo dev – lessons learned

#9
post #5

Unsure if you're able to but can you speak to how many users you have? Have you done advertising? What rate do people sign up for it now that your on a subscription.

Advertising: Zero paid advertising so far. All organic - App Store search, word of mouth, a few blog mentions. First HN post and review in German print Magazine helped a lot.

Subscription journey: Started with one-time payment, but hard to justify ongoing development time. Switched to subscription. Not everybody was amused.

First model was freemium – one playlist with max 10 tracks for free. Felt too limiting for new users trying to understand the app.

In December I changed it: all features free to explore, unlimited playlists, all content. Subscription only kicks in when you open the audio player – with 1 month free trial. Since then, good numbers daily with users worldwide. Feels more honest and converts better.

Re: Tell HN: 2 years building a kids audio app as a solo dev – lessons learned

#10

How much work was it to comply with Spotify's design and branding guidelines when using their content? https://developer.spotify.com/documentation/design#introduct...

Straightforward. Use official assets, don't modify icons, show attribution.

Tech side: I use both iOS SDK and Web API. Users create their own Spotify app in the developer dashboard to connect – keeps me out of API quota issues.

Post reply on HN