I think everyone can agree that we won't survive long as indie developers if we can only charge one or two dollars for our apps. I don't even think $15 is enough unless you have an enormous audience. So what do we do? How do we compete with the "race to the bottom" inspired by the App Store? I don't have all the answers, but I do have my opinions and I'm willing to back them up with evidence through my business actions.
Doubling Down
Michael Jurewitz gave a great talk on the economics of software pricing at Çingleton and expanded that talk at NSConference 5. You need to watch the videos to see all the details, but the high point for me was when he said, "Take your current price and double it. If you lose less than 50 percent of your unit sales, you're making more money."
Less tech support and more revenue. That sounds good to me. When others were telling me that I should lower the price of MoneyWell when the Mac App Store appeared, I refused. I know what my software is worth and what I need to grow my company and a $50 price is as low as I'll go for an app that could save my customers hundreds of dollars a year and improve their financial futures.
Back in the '90s at one of my previous companies, I wrote vertical market estimating software for the construction industry. We sold our software for $2,995 when our competitors were selling their products at four to five times our price. Were we making five times as many unit sales as them? No possible way.
So we hired a sales consultant to improve our techniques and he immediately asked why we were selling a premium product at discount pricing. He said, "Double your price and I guarantee you will only make more money." Nervously, we announced to our customers that the new price would be $6,000 and to buy additional seats before June 1.
The result? A very healthy seven-figure sales month for May and then unit sales leveled off to exactly what they were at half the price. We doubled our revenue. How much freaking money had we been leaving on the table all those years? What could we have done with our products with that added money? Shame on us.
Not every market can handle a 2x price increase, but the experiment is worth it for so many developers.
Subscription Pricing
Another wise developer and friend, Manton Reece, talked about subscription pricing. He gave us examples of how well this works with the new Microsoft and Adobe pricing and also with his some of his own software, which he was too modest to pitch, so I'll do it for him. Check out SearchPath, Tweet Library, and Watermark—they are great products.
Chatting with Manton after his talk, we discussed what software this model works for best and the simple answer is any software with a cloud back end. It's not going to work for simple device-centric apps, but if you can fit this model, it's a great option. Think about being able to lower the price point of acquiring your product and then having more balanced revenue figures for each month throughout the year. I know I wouldn't mind few valleys amongst the hills.
In-App Purchase
Since my price point is pretty solid and my products don't fit the subscription model, I'm choosing too go a different direction: In-App Purchase (IAP).
One of my biggest frustrations with the App Store is lack of trials or demos. Offering a "lite" version of an app just adds clutter and confusion, so we have a trial version on our website for our Mac app to allow customers to try MoneyWell before shelling out 50 bucks. This is not an option for iOS so I needed another solution.
Chatting with Michael Jurewitz at WWDC 2012, we came to the conclusion that IAP could work well for No Thirst apps. Last month we shipped MoneyWell Express and proved that it is a viable option with a consistent 25 percent IAP purchase rate.
MoneyWell Express is a companion app that syncs with MoneyWell on the Mac and allows for quick entry of your transactions during checkout at a store or restaurant. The fact that most people installing it are most likely existing customers skews the IAP units numbers a bit, but I'm still very happy with this adoption rate. We'll get more interesting figures when we release our iPad version, which will be standalone.
It's important to choose wisely with IAP divisions in your app. For MoneyWell, we played with different features at lower prices adding up to the price we wanted, but it got too messy. Instead we decided that the free version would allow for access to all the features and just limit the customer to a singe bank account. Most people have checking and savings accounts with a credit card or two so we were confident that they would want to purchase our "Unlimited Accounts" IAP and not settle for the limitation.
If a customer did only have one account, they would never be nagged to purchase anything. Those that did have multiple accounts would get to use all the features, but only one account would show a balance in their Accounts list. The others would have the word "locked" there instead. Tapping one of those locked accounts presented the IAP screen where a purchase removes any hint of IAP in our app.
It's a very soft sell and lets us charge more for the app than we could without that initial free experience. I want to keep our iPad app pricing in line with our Mac apps because they are going to be nearly feature equivalent to each other. Why charge less for the same functionality?
We have not seen a serious uptick in support and our ratings have been averaging four stars, but if your app has a serious learning curve, the IAP model may cost you in sales or support. I'll report back on our iPad experience when we ship it later this year. I'm optimistic that it will be excellent.
Peace.
