A common piece of feedback regards my latest app is that it’s too expensive. It costs €2.69 ($2.99); considering the usage customers are getting from it, I (and, more importantly, they) consider it very good value for money.
It’s the first time I’ve really ever had to face the software pricing dilemma and it made me wonder:
“Why is there such a gulf between what an app developer & a consumer thinks their software is worth?”
When it comes to mobile apps, a common pricing comparison is the cup of coffee which generally costs about two bucks. Take the top 20 paid apps in the App Store right now and the average price is €2.10. This makes sense as the average consumer is willing to pay about 99c/€1.99 for an app.
However, once you go above the two quid price range, things get a little more complicated. It seems as though an app priced at €2.59 can no longer be considered an impulse purchase. A developer that decides to charge more than three bucks for their work can often be met with a ferocious anger that is usually more at home at a right-wing BNP rally.
Going back to our cup of coffee comparison, you’re probably happy paying two quid for a quick take-away. Chances are, though, that you won’t mind paying 40-50% extra for something more up-market and it’s here where our comparison breaks down. With mobile apps, we have a consumer expectation chart that looks a little like this:
Perhaps the problem is consistency. You generally know what you’re getting when you pick up your morning mug o’ joe. Apps are different. Their price often doesn’t reflect their true quality. Great apps sell for 99c; pure muck sells for €3.69.
App Store reviews are practically useless since so little detail goes into them. Consumers generally give an app a rating of 1 star (“total waste of money #lolz”) or 5 stars (“BEST. APP. EVER.”). This doesn’t help us in our buying decision. Besides reading through a lot of reviews, ratings are pointless.
The problem is: there is no quick way for the consumer to discern whether an app is good or bad value for money.
I love a good whinge but I’m actually going to offer a solution so bear with me.
Let’s take a second to break down “good value”. One way of rating an app’s value is:
- How well it does the intended job?
- How often you need that job done?
The first question should be answered by ratings/reviews but, as I’ve already explained, this approach is broken.
However, it’s really easy to measure how often you need a job done and (to use some of Clay Christensen’s terminology) how often you hire an app to do that particular job. Different apps will serve different purposes, thus expecting different usages:
- You hire the FaceSwap app to see what your face would look like on your dog’s body. You hire it to give you a laugh but you don’t expect to use it for hours on end.
- You hire Hipster CEO to prove how successful you could be at running your own startup. You might expect to play this on your commute or while at home when you have some spare time. You expect several hours of playability.
- You hire TweetBot to interact with your Twitter followers. You expect to dip in and out of this several times a day and use it until the next version is released/Twitter goes out of business (probably the former).
An argument against adopting the actual usage vs. expected usage metric is that it leaves important factors like design, stability, usability etc. out of the conversation. But one of the brilliant things about the App Store is that there’s almost always another app out there to hire to solve your problem, whether that problem be getting a quick laugh, updating a Google Doc or messaging friends.
Instead of rating an app, customer’s will be voting with their home button. How many times have downloaded a bad app, opened it once and never used it again? Conversely, I bet you have an app you paid a 99c for you use on a weekly or even daily basis.
This would be so easy to implement too. Developers could select from tiered expected usage the same way we select tiered pricing.
After gathering enough (anonymous) data, the results are easily displayed like so:
So real world situation time: let’s take two apps which solve the same problem. Let’s say they are simple parsers which deliver content from the popular news sites around the web. This is something you’d expect to get quite a lot of usage from (let’s say at least 24 – 48 hours).
App X is priced 99c and is a pain to use, takes ages to load and hasn’t been updated to iOS 7 UI. App Y costs €3.59, it looks fresh, loads fast and does the job reliably.
Let’s say App X is represented by the Expected Usage image on the right and App Y by the one in the middle.
Clearly App Y is better value for money, despite being 3.5 times the cost of App X.
Of course, this approach will only work if Apple makes the refund process easier. We’ve all paid for an app and put up with it’s flaw’s purely because we’ve made the monetary investment.
There is still a lot more to app’s quality than it’s usage but representing quality wasn’t the problem. The problem was shortening the gulf between consumer and developer’s expectations; communicating the value it is for money would go a long way towards that.