How I Price Apps

[I get asked a lot of questions about what life is like as an indie app developer, so I've decided to write a series of posts on topics that frequently come up when having a beer or coffee with friends who wonder what it's like behind the scenes. Filed under openkimono.]

I often run into people who are thinking of making an app or are in the process of developing their first app ask me how I determine what price to sell an app. I've experimented with a lot of different pricing strategies over the last few years, but these days I stick with the same formula.

It's probably not for everyone, but it works for me. The reason I like this approach is that I used to waste a lot of brain cycles trying different prices and measuring the effects. Now I no longer spend time thinking about this and just focus on new ideas or coding.

Android Pricing

I'm kind of the exception in that my Android apps make more money than my iPhone apps, so this is where my focus is.

I usually release a paid, full version of an app and a free, ad-supported version around the same time (often the paid version on a Friday/Saturday and the free version the following weekend).

The paid version starts out at $0.99. The intent is to get as many downloads as possible and get feedback from initial customers. The market ranking is also probably affected by number of downloads/active installs.

When the paid app hits 500 downloads, I've usually gotten a lot of emails on what features to add and bugs to fix, and have made several updates. By then, it's a much more polished product, so I raise the price to $1.99. Some apps never reach this point, so just stay at $0.99. I can usually tell fairly quickly whether an app is going to be successful based on how many emails I get from excited initial users asking me to add XX or YY feature.

After the paid version hits 1,000 downloads, I'll raise the price again to $2.99. When I first started doing this, I was fully prepared to lower the price back to $1.99 quickly if sales dropped, but that was never the case, so I don't even consider it anymore.

iPhone Pricing

For my iPhone apps, it's a little different because on the iPhone side you can change an app from Free to Paid quickly. (Don't try this on Android, once you make an app free, you'll be stuck and won't be able to change it back to paid.) There's also the issue of the Appstore approval time, so there's more effort in experimenting.

I haven't done any apps with In-App Purchases or Subscriptions because, as I said, the Android apps pull in the revenue, so get all the attention.

For iPhone apps I've tried some different strategies, but what I do now is release a free app to evaluate the market. Sometimes I'll put in ads right away, other times I'll put ads in an early update. I'll usually alternate between using iAd and Google's Adsense for Mobile Beta. I've had more success there than with AdMob, Greystripe, Mobclix, and others. If the eCPMS are good for a particular app, I'll leave the app as free. If the niche for this app turn out to be bad for ads, I'll switch the app to the $0.99=>$1.99=>$2.99 cycle.

Going Forward/On the Horizon

This is what I've done with Android apps up till now, and it's worked for my personal, consumer-targeted apps. Unfortunately the current state of the Android Market is like the iPhone Appstore circa 2008. In-App Purchases and In-App Subscriptions changed everything in that environment. If the rumors are true and the Android Market gets either of these in 2011, there's a better approach out there.

The current app I'm working on, Field Teams, is also a different sort of animal since it's not a consumer play. It's free and has no ads. For most companies, the free service is all you need. The Pro version is in the works, so…stay tuned.

Tags: iphone, android, openkimono, app price