Lesson learned: Charge more. Then double it.
After that lesson you might expect I’d announce I’ll be raising my price to $49.99 with v2.
I’m going free up front with Slopes 2.
A lot of things have lead to this decision. I need to remove every barrier I can in acquiring and keeping users, while still also making a living. Paid up front adds too many barriers.
The Acquisition Barrier & Free Trials
One of the biggest barriers to entry for someone to try my app is having a price on it. Hence the constant complaining that we can’t make a living on the App Store without free trials. What devs usually want when they complain about a lack of free trials is the ability to cut a user off from using their app after X days. A trial like this fits nicely into the paid up front pricing model mentality: it’s just a time-delayed version of it.
A time-based trial is also appealing because it’s an easy business model with less risk. Just like a purchase of a paid app, it’s all or nothing. A user either likes the app enough to pay, or they are willing to be locked out from using it. You just need to make sure your app as a whole has enough of the right features for a user to want to pay when the trial expires.
For apps that can have a more granular view of their features than all or nothing, free trials are certainly possible on the platform today, and tons of apps already have ’em in all kinds of shapes and sizes. Premium in-app unlocks, consumables, and subscriptions are popular ones we see today.
It’s a harder route to take, from a business perspective, and I don’t want to trivialize that fact. You need to have enough features in your app that some can be free, and some can be paid. You have to make sure your app isn’t useless without paying, but that the features you pay for are compelling enough to warrant a purchase. You need to make sure you market your paid features well enough to users that they’re aware of ‘em.
The required balance of all these requirements makes it easier to fail along the way, as messing up any one requirement can tank your conversion rate. Plenty of apps failed because they couldn’t find this balance when they tried. I’d even argue that for some apps there is no way to find this balance.
The balance for each requirement isn’t something you can force. The tricky part is that the balance might be there, but it isn’t obvious; you might have to look hard to find a natural way to meet these requirements.
We aren’t alone in needing to find this balance, though. Many web SaaS products offer a free tier to gain marketshare and go through the same balancing act to make sure conversions happen. And just like us they don’t have some benevolent company making things easy by handing them a free-trial SDK, they need to implement all the code to power this division of features and tracking subscriptions themselves.
The fitness category is ripe with examples of successful free-up front apps, and I feel I can find a successful balance with Slopes too.
The Churn Barrier & Paid Upgrades
Slopes 1 is selling reasonably well, netting $10k over the last year 1and growing. Eventually, though, I’m going to saturate the market of people willing to pay up front for my app (a small subset of the niche skiing and snowboarding market, to be sure).
This isn’t an issue today, and might not be an issue for a winter or two, but it will happen. It always happens. Sales will start to decrease instead of going up and I’ll need to launch a version as a paid upgrade.
In his talk at CocoaLove 2015, Allen Pike gave a short reading of tweets complaining about v4 of Tweetbot on iOS and the requirement to pay for the updated version.
We all had a good laugh, but the truth stings: the mass market hates being asked to pay again. This is a barrier to keeping users on your app long-term: it causes churn. Either resenting you for being greedy or feeling that your previous version was good enough, they will stop upgrading over time. 2
I’d rather experiment with changing my business model before that becomes a problem, plug that churn leak, and hopefully avoid the flaming bags of poop left at my virtual doorstep.
The Survival Barrier & Revenue Per User
Lesson learned: Charge more. Then double it.
Here’s the thing: if I want any kind of serious chance to grow this into a business and do more for my users I need to find a way to charge more. My current price of $7.99 would be considered by many a premium price point, but even at that I have practically no money for user acquisition through advertising or customer support.
I can’t just rely on selling more copies to make up for my ongoing costs. That brings on more users, with more potential costs. Sure, some of those users will never cost me a dime, but over time the chance of any given user emailing me for support goes up. I have a bunch of features I’d like to implement that will require some level of human curation and data-pruning on the backend as I grow, and I need to have the revenue to support that.
Eventually that cost per user will catch up with me unless I can charge an outrageous (in users’ eyes) up front fee.
I know the value of my app: at the end of the day Slopes is considered entertainment. Fairly so as I’m not making my users money with it. If I raised my price to say $50 to increase my revenue per user I’d lose so many sales that I’d have less revenue coming in monthly. I can’t scale up in up front price. That is partly because users can’t try my app first, which free time-limited trials from Apple could help with, but it’s more-so because I’m competing with real-world costs like lift tickets, gas, food, and everything else actually required to ski and snowboard.
I can’t raise my price, so the popular wisdom of the App Store is to make it up in volume. But unless my app is self-sustained with no room for ongoing costs the cost per user will eventually catch up with me. So I can’t make it up in volume.
If I can’t make it up in volume, I’ll make it up over time.
Originally published at blog.curtisherbert.com on October 26, 2015.