Live data from Hacker News

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

news.ycombinator.com

51–60 of 84 posts

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

#52
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.

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

#53

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!

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

#54
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!

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

#55
post #51

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.

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

#56

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!

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

#58

"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!

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

#59

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.

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

#60
> 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.

Post reply on HN