AH Primetime: How Developers Settle On The Cost For Apps

January 17, 2016 - Written By Daniel Fuller

App pricing is a strange beast indeed. If you have an Apple device or two lying around or happen to follow iOS news as well as developments on the Android side of the fence, you may be familiar with the CARROT suite of apps. Developed by Brian Mueller, this suite incudes a wide range of apps and is fairly popular on iOS and Mac, although there is no presence on Android at the moment. Windows users may have also heard of Xplorer2, developed by Zabkat. A developer who had a hand in it, Nikos, is involved in this piece as well. Rounding out the group is Michael Simmons, developer for Fantastical maker Flexibits.

According to a few developers in regards to questions over app pricing and in determining a reasonable ballpark for a given app, the biggest questions to ask generally fall along the lines of what prices similar apps are going for, what makes your app different from others in that category and what the value provided may be. What would convince a user that your app is worth the amount you’re considering charging? Following this model and exercising some basic research and projection skills, you should reasonably be able to not price out your target userbase, while also not going low enough to be considered cheap crap.

Another consideration is under-the-hood charges. Some vendors of certain services, like Google Maps, charge per API call. When somebody pulls open a weather widget, opens a map or the like, that’s one API call. Normally, these fees are extremely tiny, but tend to stack up when you have a great number of users making multiple API calls in a short period. These numbers have to be accounted for in the cost, or developers can end up in the red for all their hard work.

With many apps, games in particular, there’s always the free option. You could, after careful research and optimization, sell ads within your app. If you predict the app becoming popular, this is a great way to monetize. Microtransactions for added features may also be a good idea, especially if you plan to develop this app more over time or even take user feature requests. With games, the microtransaction aspect can get a bit iffy; most users see microtransactions in a disparaging light, but they can always be supplemented, subverted with a larger one-time payment or tweaked to be more appealing to users.

A good example would be Madfinger’s Dead Trigger series. Gold, the in-game premium currency, does not come easily, but it does come. If a user pleases, they can buy more gold or in-game cash with real money to speed things along or make big purchases way earlier than they should. Keeping the in-app purchases out of the realm of necessity generally makes users think better of them, but could also result in them passing over those purchases entirely. Supplementing with ads may leave a bad taste in users’ mouths, though, forcing you to hope that purchasing users make up for non-purchasers. Thus, the importance of knowing your target market very well is shown clearly. If you’re willing to exploit human psychology, of course, you could always become the next Dong Nguyen, of Flappy Bird fame.

The cost of long term support and updates is also something that should be considered. This can get to be a gigantic use of time and is a primary expectation for most users when it comes to any paid app. In the mobile world, new OSes and core apps come out all the time and each one could potentially break your app, leading to more time sunk into updates and support. Answering user support requests is, of course, also a priority. The picture painted by these three devs in regards to app pricing is an incredibly complicated one. Many factors go into every decision from what kind of ads to run down to how much extra features should cost down the road. Hopefully, this gives some insight into why some apps wind up with such wildly different prices.