| > Charge more. I understand that you meant that it's easy to underprice the app, but as a generic pricing guideline this advice is wrong. Not considering running operational costs, the price should maximize (price x sales) figure, i.e. the revenue. It's true that in some cases doubling the price cuts the number of customers in less than a half, in which case the the "charge more" advice stands. But in other cases charging half of the current price may easily quadruple your paying userbase. Finding the right price can be done only through trying different prices. At some point Amazon was giving random discounts to their users and trying to pinpoint the ideal price for the item. It didn't last long, of course, as people started gaming them, but it just goes on to show that the price validation is a big deal. Also keep in mind if you start with $200, see zero sales and then start gradually reducing it to $20, then you basically shoot your own credibility as a merchant as the $200 -> $20 drop makes you look greedy, detached from the reality and ultimately incompetent. In the end it all very much depends on the application and the target customer base. |
I think you will find in the typically B2C sales cycle -- which is a term that makes me laugh, since it typically fits inside a browser session -- customers do not have access to the contents of your lunchbox from last Tuesday or your pricing strategy from yesterday. The only thing they see is your price, today. This is one reason that nearly everyone who starts at $200 and goes to $20 fails -- not because they "lose credibility" (no one saw the $200 price -- really, no one, the no sales problem in software is almost always caused by the marketing strategy "Put up a website and pray someone discovers it") but because charging $20 for applications communicates that the value provided by them is negligible.
(Relatedly: your competitors' pricing does not matter because your customers will probably never see it.)