3 ms·

Author here! It's a tricky question to answer. I wrote Lunar v1 in 2017, and it was fully free for 4 years, but those years were essential for the app to mature

by alin23 3y ago

Author here! It's a tricky question to answer. I wrote Lunar v1 in 2017, and it was fully free for 4 years, but those years were essential for the app to mature and get a good following. In June 2021 I launched Lunar v4 with the new support for Apple Silicon and I also added a paid tier. I started making good money from the start, most likely because Lunar was already "known". I was making about $3k/month back then, which was enough for me to not need a full time job anymore. Getting to $6k was a gradual process since 2021 until now: constantly launching free apps, giving more attention to those that provided utility to most people, adding paid tiers when I had enough to offer over the existing free features.

spike021 3y ago
How do you plan what features should be added while the app is free, and then which features in the future will go into a paid tier? Last year I worked on a pet project iOS app (which I never released unfortunately) and one of my struggles was figuring out how I'd portion out the features from free to not-free after release. I was thinking at the time of doing what you've done, basically releasing as free for a while and then adding a paid set of features. It's just difficult to plan what should fit there.
- alin23 3y ago
  If I want to build a feature that I know would need a lot of work so I’d like to make it paid, I note it down. That’s it, I just leave it there, and focus on getting the app launched as free first. After the launch, feedback will guide you through what noted features to act on, and even add some more. Launching it as free also gives you time to iron out the inevitable edge cases that won’t appear in your tests. People will have lower expectations, and feedback will contain less angry tone, which is usually a big demotivator. The “launch early” phrase you keep reading in maker circles, makes a lot of sense for indie devs. It’s easiest to validate an idea, and get help on the direction of the app. Your idea of what the app should be is not always the best idea, user feedback can help fine tune that. However if you have a very specific vision, and “if someone pays, good, if no one pays, still good”, then disregard what I said above. Keep working on your vision, something unique might sprout out of that. EDIT: I realized I might not have answered your actual question. Because I always build apps to fix a problem of my own, I make free only what’s essential for that problem. Like what I would do in a script, but with just a bit of polish and UI for it to be usable by non tech users as well. That’s how Clop launched: first it was a single Swift file that checked the clipboard for images in a loop and ran pngquant on them. I would run that at the command line. Then I packaged it as an app with minimal UI and released it as free. Most of everything else will be paid. That’s what happened with video and PDF optimization on Clop. But if it’s an improvement on an existing free feature, I will add it for free. That’s what I did with ignoring specific types of images from the clipboard, or detecting Universal Clipboard etc.

by alin23 3y ago

spike021 3y ago

How do you plan what features should be added while the app is free, and then which features in the future will go into a paid tier? Last year I worked on a pet project iOS app (which I never released unfortunately) and one of my struggles was figuring out how I'd portion out the features from free to not-free after release. I was thinking at the time of doing what you've done, basically releasing as free for a while and then adding a paid set of features. It's just difficult to plan what should fit there.

alin23 3y ago
If I want to build a feature that I know would need a lot of work so I’d like to make it paid, I note it down. That’s it, I just leave it there, and focus on getting the app launched as free first. After the launch, feedback will guide you through what noted features to act on, and even add some more. Launching it as free also gives you time to iron out the inevitable edge cases that won’t appear in your tests. People will have lower expectations, and feedback will contain less angry tone, which is usually a big demotivator. The “launch early” phrase you keep reading in maker circles, makes a lot of sense for indie devs. It’s easiest to validate an idea, and get help on the direction of the app. Your idea of what the app should be is not always the best idea, user feedback can help fine tune that. However if you have a very specific vision, and “if someone pays, good, if no one pays, still good”, then disregard what I said above. Keep working on your vision, something unique might sprout out of that. EDIT: I realized I might not have answered your actual question. Because I always build apps to fix a problem of my own, I make free only what’s essential for that problem. Like what I would do in a script, but with just a bit of polish and UI for it to be usable by non tech users as well. That’s how Clop launched: first it was a single Swift file that checked the clipboard for images in a loop and ran pngquant on them. I would run that at the command line. Then I packaged it as an app with minimal UI and released it as free. Most of everything else will be paid. That’s what happened with video and PDF optimization on Clop. But if it’s an improvement on an existing free feature, I will add it for free. That’s what I did with ignoring specific types of images from the clipboard, or detecting Universal Clipboard etc.