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.
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.
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.
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.
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.
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! ;)
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.
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!
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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! ;)
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.
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!
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.
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.
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?