The onboarding lesson is one I had to learn the hard way too. When you build something for yourself, you forget that nobody else has the mental model you do. "Figure it out yourself" feels fine when you're the user, but it's death for retention.
Also resonates with the "product first" approach. Starting with a real problem you actually have - and then following where the tech decisions naturally lead - seems to produce better outcomes than starting with "I want to build something in X framework."
The QR sharing feature is a nice touch. Physical sharing had something going for it that we lost when everything went digital - that friction-free "here, try this" moment. Recreating that digitally is harder than it sounds.
Exactly. The mental model thing is brutal. You know every corner of the app, so everything feels obvious. Then you watch someone use it for the first time and they're completely lost. Need to do that more often, perfect way to learn.
And yes - QR sharing was about bringing back that "here, just take it" moment. Sending library export as JSON, explaining how to import... too much friction. Scan and done feels right.
The mental model is usually what I want most (and often find missing) from onboarding. If you give me the model and vocabulary I can find the buttons myself. If you teach me 1 workflow I'm probably helpless at doing anything else.
100%. The goal shifted from "show where buttons are" to "explain what this app is for." Once parents get the player vs admin concept, everything else clicks.
My kid is 9. I feel like this is a good fit with how I would like her to experience music, especially the sharing and curation part. I have a few questions...
1. I bought her an "old school" mp3 player for Christmas, like an iPod. It's pretty good, but it's really missing the easy to use app similar to the original iTunes where she can load and manage songs by herself, without needing me to grab them from a folder, plug in the device, copy the songs across after it mounts, etc.
Does Muky provide that functionaliy, like an iTunes for kids before everything went streaming and on-device?
2. She also loves audiobooks. You mention audiobooks, alongside Apple Music (I don't have Spotify). Does Apple Music support audiobooks? I would love a similar interface that promotes discover of songs, but for audiobooks.
Congrats on getting this out there. I truely believe there is a viable niche for kids music apps that sits between toddler and access to all-the-music-in-the-world-at-your-fingertips that becomes a huge time sink for kids who can't quite self regulate the shiny interface of modern streaming apps on mobile phones. I almost went down a rabbithole of building one myself, thinking, how hard can it be...thank you for saving me the 2 years to understand its hard! :-)
Thanks! You nailed the niche – that gap between toddler devices and full streaming access is exactly where Muky sits.
To your questions:
1. Unfortunately no – Muky only works with streaming content from Apple Music or Spotify. No local MP3 support or syncing to external devices. You'd still need something like the old iTunes workflow for that MP3 player. Local file support comes up often though, it's on the roadmap.
2. There's actually a lot of audiobook content on Apple Music – especially kids stuff. The new Browse tab in Mukychas curated audiobooks to help you discover them.
And yes – "how hard can it be" is a dangerous question. Found that out myself!
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.
Makes sense. Flutter has a good reputation - I've heard mostly positive things.
For me, I had bad experiences with React Native in the past and already built another iOS app in Swift. Knew the ecosystem, liked SwiftUI, so sticking with native felt right. Less context switching, and I can use Apple frameworks directly – MusicKit for Apple Music integration and native offline playback would've been painful to wrap.
Cross-platform definitely makes sense for many projects – just wasn't the right fit for me this time.
I haven't tried anything music related, but I did have a need to embed video playback in user-created content in a consistent way across platforms. I'm pretty impressed with how that turned out.
Same here, I've slept these past few years on Flutter even when someone recommended trying it out and was pretty enthused about it. Last month I got roped in a greenfield project and allowed to chose the stack, instead of the tried and true React Native I went for Flutter and I'm glad I did so.
Also shout-out to flutter_rust_bridge and a video[0] on YouTube from a conference explaining how to fit it in, I get to use Flutter and Dart for the UI parts and everything else in Rust. Another great thing because of Flutter's hot-reload I get to avoid the sucky parts of waiting for Rust code to compile to see UI changes. I've also had good (not great) success getting Gemini 3 Pro to sketch out the initial UI and the boilerplate and that also allowed me to move a bit faster than I would've otherwise.
Flutter + Rust sounds like a solid combo. A lot of colleagues swear by Rust – been meaning to dig deeper. Will check the video, thanks!
Hot-reload is something I miss in native – SwiftUI previews help but not the same. For my use case native made sense, but I can see why Flutter wins for greenfield projects with multi-platform needs.
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?
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.
I’m currently using a Yoto (3 devices) with my 1 and 4 year old and they thoroughly enjoy it. The MYO experience and loading up cards is pretty straightforward as well.
Love the concept here and I would be a customer if you were still offering lifetime, but with so many things going subscription nowadays adding another at $40/year just feels a bit on the higher side. Definitely understand how that assists with cash flow for ongoing development though.
Totally get it – subscription fatigue is real. Yoto is great for that age, we still have the Toniebox for our younger one.
The pricing is tricky. One-time worked for users but not for ongoing development. $40/year sounds steep, but it's ~$3.30/month – less than a single Tonie figurine. Family plan can be shared with grandparents too.
That said, I hear you. Always evaluating the model.
Totally understood. Currently we're subbed at the ~$150/year for Yoto for access to the club and credits for cards, so adding on at this point is somewhat unnecessary right now.
As they age out of Yoto this would certainly be worth it at that point.
This looks very nice, I love that you're making a real solution to avoid the dark patterns of companies like Spotify. I used Subsonic for a while as a simple way to curate music for kids and keep them off Spotify, but eventually my oldest got past the "listen to the same album over and over again" stage, and adding everything to Subsonic became a chore, so we succumbed to giving her an account. Yet I really don't like how Spotify has been adding direct messaging, Wrapped, Jams, discovery etc. – stuff that on the face of it looks fun (for adults), but when you see the addictive effect it has on the tweens it's just horrible. Technically I guess Spotify is now illegal for <16yo's in Australia.
For my youngest, I installed Qobuz, which has all the music, but much fewer features. They reportedly pay artists more per stream than any of the other apps (I guess because they don't have so many expenses for social media app development). Your app UI looks much cleaner though :)
Thanks! Yeah the dark patterns in streaming apps are rough, especially for kids. Wrapped and all that social stuff is designed to keep you hooked.
Give Muky a try if you want! Qobuz is nice – would love to add more services like Qobuz or Deezer at some point, as long as the API is good and offline listening is supported. And yeah, wish more services would adopt a user-centric payment model – would be so much better for artists.
This is one of my favorite tell/ show HN posts. Very interesting to see the reactions to your original "Show HN", and learn that was meaningful for your business.
Very well executed product and posts, and congratulations on your success!
Thanks, really appreciate that! HN has been great – the first post brought real users and valuable feedback. This community gets the indie dev journey.
Yes! I watched that talk – fascinating reverse engineering work. The custom NFC tag approach is really clever.
What stood out to me was how much data gets tracked by the original firmware. Kind of eye-opening. The custom firmware fixing that is great for privacy-conscious parents.
How do you manage promotion? I have a moderate amount of success with Reddit Posts, there is always a spike in downloads. But, going for a specific niche (a scrollable feed notes app) https://apps.apple.com/gb/app/notesub/id6742334239 means that I am never sure where I can find people who may like my app.
What's worked so far: HN posts (like this one), App Store search/optimization, and surprisingly – just parents telling other parents. I get emails from people who found Muky through friends. Slow but it sticks.
Reddit I haven't cracked yet. Parenting subs can be weird about self-promo. What subs are working for you?
Totally agree. Took me a while to get there though – early versions were very "here's a blank canvas, good luck." Turns out parents don't want to search through millions of songs. The Browse tab with curated stuff made a big difference. Thanks!
> SwiftUI is a joy to work with and performance is great.
It really is, unless you want to draw outside the lines. If I want to do anything that isn’t explicitly in the SwiftUI model, it becomes Kludgeopolis, very quickly. There’s some things that can only be done with UIViewRepresentable, which I consider to be a bit of a “white flag.”
Also, because of the way that the rules are written, it’s difficult for me to segregate areas of functionality into extension blocks (like I do, with UIKit). I tend to have fairly long blocks of code, which is less than optimal.
But the performance really is excellent, and I can often get a lot done, with much less code, than UIKit.
Never worked with hybrid systems, like React, so the same might be true for them.
Totally agree – it can get messy once you go off the beaten path. But for most things you can build so much with just SwiftUI and a few Apple frameworks. No node_modules with 500+ dependencies. Coming from web dev that still feels like a luxury.
It’s easy to build high performance custom components, for example with Canvas which is excellent. However, at the top level of an app it’s got to be the standard way.
That may be a good thing for usability across apps but it feels like a low code platform sometimes.
Know what you mean. SwiftUI can feel similar – great for standard patterns, but you hit walls when you want something custom. Ended up mixing in UIKit for some edge cases.
Trade-off I'm willing to make though. For a solo project, fast iteration beats pixel-perfect control.
Can understand – depends on the designer though! ;)
I've had both experiences. Good designers push you to make things better. But some insist on details no user will ever notice. Finding the right balance is key.
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.
I have a sneaking suspicion they might steal your idea and release their own version before they do that. But maybe you get lucky and they don't do that, so definitely go for it. Best of luck!
Congrats on the new dad status! Enjoy the early years – the Toniebox phase is actually pretty great. Muky will be waiting when they start asking for "that song from the movie" on repeat. ;)
And yes – big tech seems to avoid this space. Maybe too niche, maybe too much liability with kids content. Works for me!
Honestly, I don't think Apple would bother with this niche. They have biggAIr priorities. And if they ever did, it would validate the idea - and they'd probably do it differently anyway.
For now I'll keep building. Worst case, my kids still have a music player that works exactly how we want it. :)
Did you do the site design yourself too? Everything looks nice and polished. Mind sharing your stack for the web? How did your site fare with the traffic HN sent?
This is a genuine question that maybe dang or another mod can answer. Why is this posted as a Tell HN and not a Show HN? It feels more like the latter to me.
I set a (very) old phone into child mode total lockdown with only YouTube music installed to make use of my family account and streaming playlists ... only to find it (the YTM app) wouldn't open due to the social media ban in Australia (legislation which I otherwise - controversially - completely support).
YouTube Music would be great, but there's no official API for third-party apps. Only unofficial libraries that scrape the web interface – not something I'd want to build an app on. Too fragile and could break anytime.
Interesting about Australia – sounds like the social media ban for under-16s now includes YouTube, but YouTube Music as a pure streaming service should be separate. The ban targets social platforms with feeds and interactions. Might be worth checking if YouTube Music specifically falls under it or if the device lockdown is catching it by accident.
That's fair. Lack of any official APIs outside of the standard YT data API is frustrating. Would love to see / hear about a rosetta stone for the streaming services to allow easier migration (and integration) between them. Though I guess that's not in anyone's interest.
Also regards the ban, from what I've read Google have included Music by choice. Potentially as a bargaining chip.
This is a great idea. I’ve been thinking about making something like this for a while due to all the problems you describe.
I was planning to make something that used rfid cards to play specific songs / albums so it worked more like yoto. But that would just make it even more niche!
Thanks! The RFID approach is cool – I actually built a box with real buttons and RFID connected to our Sonos system at some point. Was fun, but in the end I prefer the digital approach. Less hardware to maintain.
And niche isn't bad – sometimes that's exactly where the best apps live.
Yeah the little hardware I had actually tried to make was so painful compared to software dev. Interested to read the part about asking users to make their own spotify dev account. How’s that going so far? Seems like it could be a big roadblock for non techy users?
Great idea. The things available to give parents controlled access to music aren't great. Echo (Dot) + Kids+ seems to be the closest to meh on the speakers--the kids devices like Yoto are too limited (or require downloads) and the other voice speakers are worse than Echo/Alexa/Kids+. Which is mind-boggling because the Echo setup is wildly bad. I was thinking about how to lock an old iPad down to nothing but this app -- will need some time looking at parental controls again. Adding respect for Explicit tags might be a good feature if you don't have it. I have playlists that I'd love to share to them, but 5% of the songs need the radio edit or need to be elided.
Thanks! For locking down the iPad – check out Guided Access (Settings > Accessibility). Locks the device to a single app, you need a PIN to exit. Works great with Muky, that's the main setup I recommend.
For speakers, I just got my daughter the Wonderboom 4 – pairs via Bluetooth, sturdy, sounds good. Combined with an old iPad it's a solid setup.
Explicit tag filtering is a good idea. Right now parents manually curate playlists, so you control what goes in. But auto-filtering based on explicit flags could help. Adding it to the list - thanks for the suggestion!
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.
> Spotify means infinite browsing, algorithm recommendations, and "Dad, how do I get back to my song?"
I hope you are successful and eventually go after video content too. Imagine a Youtube app without infinite browsing or the algo and a "you can watch 3 videos this weekend"-counter/countdown.
I like this idea, but I really don’t get it (maybe I haven’t read enough of your webpage) but how do you integrate with Spotify? Is this native or something they can block/ban. And is it possible to upload content (I have mp3s I let kids listen to on a dumb mp3 player)
Spotify integration is all official - iOS SDK for playback, Web API for fetching playlists and tracks. Users connect their own Spotify account. Nothing hacky, so no ban risk. Same for Apple Music via MusicKit.
MP3s aren't supported right now – Muky only works with streaming content. But you're not the first to ask. Adding local files to the roadmap, maybe in the future.
You might consider the approach GoodLinks and Due take which is to sell annual upgrades on subscription so people canget off the ride at some point and still not leave enptyhanded
Yeah I know that model – it's a nice middle ground. For now I'm sticking with the current approach, but good to keep in mind if things change. Thanks for the pointer!
Spotify changed their API policy last year – getting extended quota as an indie dev is tough now. They want commercial partnerships or big user numbers. By having users create their own Spotify app, each user has their own quota and I don't need to go through Spotify's approval process.
Apple Music via MusicKit doesn't have that restriction – just works with the user's subscription.
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.
Not too bad technically – Apple handles most of it with StoreKit. Maybe a week of work for the initial implementation: setting up products in App Store Connect, handling purchase flow, receipt validation, restoring purchases.
The harder part was deciding on the model. Freemium limits? Trial length? What to lock? I changed this multiple times. The code changes for each iteration were small, but the decisions took longer.
Mind sharing cashflow details? Is the business growing? Do you get a new user for every user that leaves? How do you handle converting free users into paid ones?
Don't have precise churn numbers yet – changed the subscription model in December so it's still early.
Old model: freemium with 1 playlist, max 10 tracks. Paid unlocks more. Felt limiting.
New model: everything free to explore. Build your playlists, add all content. Subscription only kicks in when you open the audio player to hand it to your kid – 1 month free trial included.
Since then daily signups are solid, users worldwide. Feels more honest – people see the full value before paying. Still indie scale, but growing steadily.
Similar story here , but started mine when first Android phones were released. Had great success. And still have. Now with AI I have 2 max accounts with Claude and I don't touch any code anymore. I went full high risk cowboy style. All code. Server management, databases, security, upgrades, root access. Access to all my accounts, keys, hashes all goes into my prompts. Everything with ai. I don't even go to the Playstore site to publish. The only thing I touch is my terminal with Claude instances and opencode, Gemini or codex as backups.
I think I now went all in about 2, 3 months ago. It does make a lot of mistakes and its cowboy style 4.0. I cant remember a case were everything became a broken chaos. I think the AI does a much better job in maintaining my machines than i could do. Its able to configure low level stuff like fail2ban, iftables perfectly fine. Its much better in reading logs or solving issues. Once in a while it makes a mistake, like misconfiguring firewal rules and lock me out. All solvable issues. Software wise its also better. Yes you are prompting in circles sometimes. But thats fine. Usually it will fix the issue I have after a few iterations. Its not so much different that normal development, but on a higher level. You are dealing with a senior developer behaving like a child.
"A senior developer behaving like a child" – ha, that's a perfect description. Knows everything but sometimes does the weirdest things.
Interesting that it handles server config well. I'm still hesitant on production systems, but maybe that changes over time. Getting locked out by misconfigured firewall rules sounds stressful though!
Honestly, still figuring this out. Tried social media (Instagram, Threads, Bluesky) and reaching out to blogs/reviewers. Gets some traction but reach is limited. A German print magazine review helped, and the first HN post brought a spike.
What's funny – parent to parent word of mouth has been really helpful. I get lots of emails from parents with ideas or bug reports. They found the app through friends or family. That feels more sustainable than any marketing trick.
But I still need to find better channels with more reach. Most growth so far has been organic via App Store search. Open to suggestions if anyone has ideas! ;)
Thanks a lot. As an unrelated follow-up, I searched for the spotify API and found that spotify changed their criteria for Web API Extended Access last year. I suppose this will not affect your app, since existing API users can continue to use it. Would the new rule affect you if you were just starting to develop this app?
Yes, that change was actually the reason I went with "users create their own Spotify app" approach. With the new criteria, getting extended quota as an indie dev is tough – Spotify wants commercial partnerships or big user numbers.
By having users create their own developer app, each user has their own quota and I stay out of the approval process entirely. Works well for a niche app like this.
The onboarding lesson is one I had to learn the hard way too. When you build something for yourself, you forget that nobody else has the mental model you do. "Figure it out yourself" feels fine when you're the user, but it's death for retention.
Also resonates with the "product first" approach. Starting with a real problem you actually have - and then following where the tech decisions naturally lead - seems to produce better outcomes than starting with "I want to build something in X framework."
The QR sharing feature is a nice touch. Physical sharing had something going for it that we lost when everything went digital - that friction-free "here, try this" moment. Recreating that digitally is harder than it sounds.
Thanks!
Exactly. The mental model thing is brutal. You know every corner of the app, so everything feels obvious. Then you watch someone use it for the first time and they're completely lost. Need to do that more often, perfect way to learn.
And yes - QR sharing was about bringing back that "here, just take it" moment. Sending library export as JSON, explaining how to import... too much friction. Scan and done feels right.
The mental model is usually what I want most (and often find missing) from onboarding. If you give me the model and vocabulary I can find the buttons myself. If you teach me 1 workflow I'm probably helpless at doing anything else.
100%. The goal shifted from "show where buttons are" to "explain what this app is for." Once parents get the player vs admin concept, everything else clicks.
My kid is 9. I feel like this is a good fit with how I would like her to experience music, especially the sharing and curation part. I have a few questions...
1. I bought her an "old school" mp3 player for Christmas, like an iPod. It's pretty good, but it's really missing the easy to use app similar to the original iTunes where she can load and manage songs by herself, without needing me to grab them from a folder, plug in the device, copy the songs across after it mounts, etc. Does Muky provide that functionaliy, like an iTunes for kids before everything went streaming and on-device?
2. She also loves audiobooks. You mention audiobooks, alongside Apple Music (I don't have Spotify). Does Apple Music support audiobooks? I would love a similar interface that promotes discover of songs, but for audiobooks.
Congrats on getting this out there. I truely believe there is a viable niche for kids music apps that sits between toddler and access to all-the-music-in-the-world-at-your-fingertips that becomes a huge time sink for kids who can't quite self regulate the shiny interface of modern streaming apps on mobile phones. I almost went down a rabbithole of building one myself, thinking, how hard can it be...thank you for saving me the 2 years to understand its hard! :-)
Thanks! You nailed the niche – that gap between toddler devices and full streaming access is exactly where Muky sits.
To your questions:
1. Unfortunately no – Muky only works with streaming content from Apple Music or Spotify. No local MP3 support or syncing to external devices. You'd still need something like the old iTunes workflow for that MP3 player. Local file support comes up often though, it's on the roadmap.
2. There's actually a lot of audiobook content on Apple Music – especially kids stuff. The new Browse tab in Mukychas curated audiobooks to help you discover them.
And yes – "how hard can it be" is a dangerous question. Found that out myself!
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.
Makes sense. Flutter has a good reputation - I've heard mostly positive things.
For me, I had bad experiences with React Native in the past and already built another iOS app in Swift. Knew the ecosystem, liked SwiftUI, so sticking with native felt right. Less context switching, and I can use Apple frameworks directly – MusicKit for Apple Music integration and native offline playback would've been painful to wrap.
Cross-platform definitely makes sense for many projects – just wasn't the right fit for me this time.
Recently Skip got open source, so perhaps you can even make an android application out of it?
Thoughts?
https://news.ycombinator.com/item?id=46706906
Interesting, hadn't seen Skip before. SwiftUI to Android sounds promising.
Bookmarked – will look into it. Still hoping native Swift for Android matures, but Skip could be a good middle ground. Thanks for the pointer!
I haven't tried anything music related, but I did have a need to embed video playback in user-created content in a consistent way across platforms. I'm pretty impressed with how that turned out.
Same here, I've slept these past few years on Flutter even when someone recommended trying it out and was pretty enthused about it. Last month I got roped in a greenfield project and allowed to chose the stack, instead of the tried and true React Native I went for Flutter and I'm glad I did so.
Also shout-out to flutter_rust_bridge and a video[0] on YouTube from a conference explaining how to fit it in, I get to use Flutter and Dart for the UI parts and everything else in Rust. Another great thing because of Flutter's hot-reload I get to avoid the sucky parts of waiting for Rust code to compile to see UI changes. I've also had good (not great) success getting Gemini 3 Pro to sketch out the initial UI and the boilerplate and that also allowed me to move a bit faster than I would've otherwise.
[0] https://youtu.be/yZ0XHRfU7Ao?si=JQXHS61ycxVSq9GF
Flutter + Rust sounds like a solid combo. A lot of colleagues swear by Rust – been meaning to dig deeper. Will check the video, thanks!
Hot-reload is something I miss in native – SwiftUI previews help but not the same. For my use case native made sense, but I can see why Flutter wins for greenfield projects with multi-platform needs.
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.
I’m currently using a Yoto (3 devices) with my 1 and 4 year old and they thoroughly enjoy it. The MYO experience and loading up cards is pretty straightforward as well.
Love the concept here and I would be a customer if you were still offering lifetime, but with so many things going subscription nowadays adding another at $40/year just feels a bit on the higher side. Definitely understand how that assists with cash flow for ongoing development though.
Totally get it – subscription fatigue is real. Yoto is great for that age, we still have the Toniebox for our younger one.
The pricing is tricky. One-time worked for users but not for ongoing development. $40/year sounds steep, but it's ~$3.30/month – less than a single Tonie figurine. Family plan can be shared with grandparents too.
That said, I hear you. Always evaluating the model.
Totally understood. Currently we're subbed at the ~$150/year for Yoto for access to the club and credits for cards, so adding on at this point is somewhat unnecessary right now.
As they age out of Yoto this would certainly be worth it at that point.
This looks very nice, I love that you're making a real solution to avoid the dark patterns of companies like Spotify. I used Subsonic for a while as a simple way to curate music for kids and keep them off Spotify, but eventually my oldest got past the "listen to the same album over and over again" stage, and adding everything to Subsonic became a chore, so we succumbed to giving her an account. Yet I really don't like how Spotify has been adding direct messaging, Wrapped, Jams, discovery etc. – stuff that on the face of it looks fun (for adults), but when you see the addictive effect it has on the tweens it's just horrible. Technically I guess Spotify is now illegal for <16yo's in Australia.
For my youngest, I installed Qobuz, which has all the music, but much fewer features. They reportedly pay artists more per stream than any of the other apps (I guess because they don't have so many expenses for social media app development). Your app UI looks much cleaner though :)
Thanks! Yeah the dark patterns in streaming apps are rough, especially for kids. Wrapped and all that social stuff is designed to keep you hooked.
Give Muky a try if you want! Qobuz is nice – would love to add more services like Qobuz or Deezer at some point, as long as the API is good and offline listening is supported. And yeah, wish more services would adopt a user-centric payment model – would be so much better for artists.
This is one of my favorite tell/ show HN posts. Very interesting to see the reactions to your original "Show HN", and learn that was meaningful for your business.
Very well executed product and posts, and congratulations on your success!
Thanks, really appreciate that! HN has been great – the first post brought real users and valuable feedback. This community gets the indie dev journey.
Regarding the Toniebox and custom audiobooks - do you know that there’s a tool to add audio files that can be triggered by custom NFC tags?
Here’s the talk about it:
https://media.ccc.de/v/37c3-11993-toniebox_reverse_engineeri...
And the project website:
https://tonies-wiki.revvox.de/
There’s even a custom firmware that can send activity data to Home Assistant, can pull audio from a local server, etc.
Yes! I watched that talk – fascinating reverse engineering work. The custom NFC tag approach is really clever.
What stood out to me was how much data gets tracked by the original firmware. Kind of eye-opening. The custom firmware fixing that is great for privacy-conscious parents.
Impressive work.
How do you manage promotion? I have a moderate amount of success with Reddit Posts, there is always a spike in downloads. But, going for a specific niche (a scrollable feed notes app) https://apps.apple.com/gb/app/notesub/id6742334239 means that I am never sure where I can find people who may like my app.
I like the UI of your app btw.
Thanks! Honestly still figuring this out myself.
What's worked so far: HN posts (like this one), App Store search/optimization, and surprisingly – just parents telling other parents. I get emails from people who found Muky through friends. Slow but it sticks.
Reddit I haven't cracked yet. Parenting subs can be weird about self-promo. What subs are working for you?
Your app looks good, too!
"Finally feels like the app helps you instead of just waiting for input."
I've noticed a trend that most popular apps nowadays are the ones that serve this model.
Totally agree. Took me a while to get there though – early versions were very "here's a blank canvas, good luck." Turns out parents don't want to search through millions of songs. The Browse tab with curated stuff made a big difference. Thanks!
> SwiftUI is a joy to work with and performance is great.
It really is, unless you want to draw outside the lines. If I want to do anything that isn’t explicitly in the SwiftUI model, it becomes Kludgeopolis, very quickly. There’s some things that can only be done with UIViewRepresentable, which I consider to be a bit of a “white flag.”
Also, because of the way that the rules are written, it’s difficult for me to segregate areas of functionality into extension blocks (like I do, with UIKit). I tend to have fairly long blocks of code, which is less than optimal.
But the performance really is excellent, and I can often get a lot done, with much less code, than UIKit.
Never worked with hybrid systems, like React, so the same might be true for them.
Totally agree – it can get messy once you go off the beaten path. But for most things you can build so much with just SwiftUI and a few Apple frameworks. No node_modules with 500+ dependencies. Coming from web dev that still feels like a luxury.
It’s easy to build high performance custom components, for example with Canvas which is excellent. However, at the top level of an app it’s got to be the standard way.
That may be a good thing for usability across apps but it feels like a low code platform sometimes.
Know what you mean. SwiftUI can feel similar – great for standard patterns, but you hit walls when you want something custom. Ended up mixing in UIKit for some edge cases.
Trade-off I'm willing to make though. For a solo project, fast iteration beats pixel-perfect control.
> fast iteration beats pixel-perfect control
Wait until you work with a professional designer. They insist on perfection. Can drive me nuts.
But I have to admit; the projects that I’ve done with designers, are a lot more popular than the ones I did, myself.
Can understand – depends on the designer though! ;)
I've had both experiences. Good designers push you to make things better. But some insist on details no user will ever notice. Finding the right balance is key.
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.
> ... if Apple grants me the entitlement.
I have a sneaking suspicion they might steal your idea and release their own version before they do that. But maybe you get lucky and they don't do that, so definitely go for it. Best of luck!
They could. So could Spotify. But in general the big tech products really seem allergic to the problems OP is after.
Anyway I’m a newly minted dad and I’m bookmarking this for a few years out. Congrats! This is brilliant and feels inspired.
Congrats on the new dad status! Enjoy the early years – the Toniebox phase is actually pretty great. Muky will be waiting when they start asking for "that song from the movie" on repeat. ;)
And yes – big tech seems to avoid this space. Maybe too niche, maybe too much liability with kids content. Works for me!
Honestly, I don't think Apple would bother with this niche. They have biggAIr priorities. And if they ever did, it would validate the idea - and they'd probably do it differently anyway.
For now I'll keep building. Worst case, my kids still have a music player that works exactly how we want it. :)
Did you do the site design yourself too? Everything looks nice and polished. Mind sharing your stack for the web? How did your site fare with the traffic HN sent?
This is a genuine question that maybe dang or another mod can answer. Why is this posted as a Tell HN and not a Show HN? It feels more like the latter to me.
On the topic of Yoto I made an app[0] that helps you load audio from Youtube into playlists
[0]https://github.com/cjlm/yoto-playlist-creator
Nice! Yoto + YouTube audio is a clever combo. Will check it out.
YouTube music support? (ᵕ•_•)
I set a (very) old phone into child mode total lockdown with only YouTube music installed to make use of my family account and streaming playlists ... only to find it (the YTM app) wouldn't open due to the social media ban in Australia (legislation which I otherwise - controversially - completely support).
YouTube Music would be great, but there's no official API for third-party apps. Only unofficial libraries that scrape the web interface – not something I'd want to build an app on. Too fragile and could break anytime.
Interesting about Australia – sounds like the social media ban for under-16s now includes YouTube, but YouTube Music as a pure streaming service should be separate. The ban targets social platforms with feeds and interactions. Might be worth checking if YouTube Music specifically falls under it or if the device lockdown is catching it by accident.
That's fair. Lack of any official APIs outside of the standard YT data API is frustrating. Would love to see / hear about a rosetta stone for the streaming services to allow easier migration (and integration) between them. Though I guess that's not in anyone's interest.
Also regards the ban, from what I've read Google have included Music by choice. Potentially as a bargaining chip.
This is a great idea. I’ve been thinking about making something like this for a while due to all the problems you describe.
I was planning to make something that used rfid cards to play specific songs / albums so it worked more like yoto. But that would just make it even more niche!
Good luck you you!
Thanks! The RFID approach is cool – I actually built a box with real buttons and RFID connected to our Sonos system at some point. Was fun, but in the end I prefer the digital approach. Less hardware to maintain.
And niche isn't bad – sometimes that's exactly where the best apps live.
Yeah the little hardware I had actually tried to make was so painful compared to software dev. Interested to read the part about asking users to make their own spotify dev account. How’s that going so far? Seems like it could be a big roadblock for non techy users?
Great idea. The things available to give parents controlled access to music aren't great. Echo (Dot) + Kids+ seems to be the closest to meh on the speakers--the kids devices like Yoto are too limited (or require downloads) and the other voice speakers are worse than Echo/Alexa/Kids+. Which is mind-boggling because the Echo setup is wildly bad. I was thinking about how to lock an old iPad down to nothing but this app -- will need some time looking at parental controls again. Adding respect for Explicit tags might be a good feature if you don't have it. I have playlists that I'd love to share to them, but 5% of the songs need the radio edit or need to be elided.
Thanks! For locking down the iPad – check out Guided Access (Settings > Accessibility). Locks the device to a single app, you need a PIN to exit. Works great with Muky, that's the main setup I recommend.
For speakers, I just got my daughter the Wonderboom 4 – pairs via Bluetooth, sturdy, sounds good. Combined with an old iPad it's a solid setup.
Explicit tag filtering is a good idea. Right now parents manually curate playlists, so you control what goes in. But auto-filtering based on explicit flags could help. Adding it to the list - thanks for the suggestion!
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.
> Spotify means infinite browsing, algorithm recommendations, and "Dad, how do I get back to my song?"
I hope you are successful and eventually go after video content too. Imagine a Youtube app without infinite browsing or the algo and a "you can watch 3 videos this weekend"-counter/countdown.
Ha, I'd love that too! YouTube for kids is a nightmare – even YouTube Kids has weird rabbit holes.
Video is tempting but a different beast – streaming APIs, licensing, way more complex. Maybe someday. For now staying focused on audio.
I like this idea, but I really don’t get it (maybe I haven’t read enough of your webpage) but how do you integrate with Spotify? Is this native or something they can block/ban. And is it possible to upload content (I have mp3s I let kids listen to on a dumb mp3 player)
Spotify integration is all official - iOS SDK for playback, Web API for fetching playlists and tracks. Users connect their own Spotify account. Nothing hacky, so no ban risk. Same for Apple Music via MusicKit.
MP3s aren't supported right now – Muky only works with streaming content. But you're not the first to ask. Adding local files to the roadmap, maybe in the future.
Thanks for the response
You might consider the approach GoodLinks and Due take which is to sell annual upgrades on subscription so people canget off the ride at some point and still not leave enptyhanded
Yeah I know that model – it's a nice middle ground. For now I'm sticking with the current approach, but good to keep in mind if things change. Thanks for the pointer!
Why do you need a Spotify Developer account but not Apple Music?
Spotify changed their API policy last year – getting extended quota as an indie dev is tough now. They want commercial partnerships or big user numbers. By having users create their own Spotify app, each user has their own quota and I don't need to go through Spotify's approval process.
Apple Music via MusicKit doesn't have that restriction – just works with the user's subscription.
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.
What was the level of (development) effort switching to subscription?
Not too bad technically – Apple handles most of it with StoreKit. Maybe a week of work for the initial implementation: setting up products in App Store Connect, handling purchase flow, receipt validation, restoring purchases.
The harder part was deciding on the model. Freemium limits? Trial length? What to lock? I changed this multiple times. The code changes for each iteration were small, but the decisions took longer.
Mind sharing cashflow details? Is the business growing? Do you get a new user for every user that leaves? How do you handle converting free users into paid ones?
Don't have precise churn numbers yet – changed the subscription model in December so it's still early.
Old model: freemium with 1 playlist, max 10 tracks. Paid unlocks more. Felt limiting.
New model: everything free to explore. Build your playlists, add all content. Subscription only kicks in when you open the audio player to hand it to your kid – 1 month free trial included.
Since then daily signups are solid, users worldwide. Feels more honest – people see the full value before paying. Still indie scale, but growing steadily.
Similar story here , but started mine when first Android phones were released. Had great success. And still have. Now with AI I have 2 max accounts with Claude and I don't touch any code anymore. I went full high risk cowboy style. All code. Server management, databases, security, upgrades, root access. Access to all my accounts, keys, hashes all goes into my prompts. Everything with ai. I don't even go to the Playstore site to publish. The only thing I touch is my terminal with Claude instances and opencode, Gemini or codex as backups.
That's bold! Full AI-driven, including deploys and server access – respect for going all in.
Curious how you handle when AI makes mistakes on production systems?
I think I now went all in about 2, 3 months ago. It does make a lot of mistakes and its cowboy style 4.0. I cant remember a case were everything became a broken chaos. I think the AI does a much better job in maintaining my machines than i could do. Its able to configure low level stuff like fail2ban, iftables perfectly fine. Its much better in reading logs or solving issues. Once in a while it makes a mistake, like misconfiguring firewal rules and lock me out. All solvable issues. Software wise its also better. Yes you are prompting in circles sometimes. But thats fine. Usually it will fix the issue I have after a few iterations. Its not so much different that normal development, but on a higher level. You are dealing with a senior developer behaving like a child.
"A senior developer behaving like a child" – ha, that's a perfect description. Knows everything but sometimes does the weirdest things.
Interesting that it handles server config well. I'm still hesitant on production systems, but maybe that changes over time. Getting locked out by misconfigured firewall rules sounds stressful though!
Love the idea.
If you don't mind sharing, besides producthunt launches, how have you promoted it?
Thanks!
Honestly, still figuring this out. Tried social media (Instagram, Threads, Bluesky) and reaching out to blogs/reviewers. Gets some traction but reach is limited. A German print magazine review helped, and the first HN post brought a spike.
What's funny – parent to parent word of mouth has been really helpful. I get lots of emails from parents with ideas or bug reports. They found the app through friends or family. That feels more sustainable than any marketing trick.
But I still need to find better channels with more reach. Most growth so far has been organic via App Store search. Open to suggestions if anyone has ideas! ;)
Thanks a lot. As an unrelated follow-up, I searched for the spotify API and found that spotify changed their criteria for Web API Extended Access last year. I suppose this will not affect your app, since existing API users can continue to use it. Would the new rule affect you if you were just starting to develop this app?
Yes, that change was actually the reason I went with "users create their own Spotify app" approach. With the new criteria, getting extended quota as an indie dev is tough – Spotify wants commercial partnerships or big user numbers.
By having users create their own developer app, each user has their own quota and I stay out of the approval process entirely. Works well for a niche app like this.
More context here: https://community.spotify.com/t5/Spotify-for-Developers/Upda...