Interesting, so 6000 x 2 ($12,000) vs 300 x 14 ($4,200) a price elasticity factor of 3.
If you are reading John, how did you pick $14 as the price? Pricing software is always difficult because you marginal costs are 0.
One school of thought is to take the time needed to write something, pick an hourly rate of what you would have had to pay a person to write it (or use what it cost you to produce it [1]) and then divide by the 'nominal' market to get a price.
Working a contrived example, lets say you write an App all by yourself, it takes you 3 weeks and you put in 300 hrs of work over those three weeks. Now you say "My time is worth $100/hr" so you've invest $30,000 into building that App. Now if the 'nominal market' which is people that you think need this capability at any cost is 1,000 people, you might charge $30/.3 or $100 ($99.95 if you're clever) for the app. After capturing your 1000 sales you've covered your development cost and are 'profiting' on the long tail with additional sales.
The danger of course is that you can over value your time and over estimate the number of people who might want your product.
[1] Cost to produce can be tricky if you are building several things, how much of your UI design developer do you charge to one project or another? Even fractions is a common technique but the designer will tell you that some projects took more of their time than others so its not a perfect strategy.
Honestly, I don't think this is the right approach. Development time is a sunk cost at this point, and doesn't have any impact of the profitability of the app in the future. John's only concern now should be maximizing profit, and profit's going to be a function solely of the market for his app.
The type of analysis you've described is more applicable to consulting work, where there's a hard limit to how much output you can produce.
Fair enough. I am interested in the general question "pricing software" and explained my reasoning for how I might go about pricing an App. If John is reading I would really like to know what his reasoning is. The data points we have from the article are "originally priced at $14" "Priced one day at $2" "Made $8000 which is more than they expected to make" these are all pieces of data regarding his reasoning but I'm truly interested in how he thinks about it. Why was $8,000 more than he expected, how much did he expect? If he had no idea how much did he guess? What reasoning did he use to inform that guess?
"App stores" are an amazingly disruptive power on software development costs. I find them fascinating both from a business perspective and from a more general economics perspective. Perhaps someone else reading this will some day post their experiences to HN as well and we'll another data point.
If you are reading John, how did you pick $14 as the price? Pricing software is always difficult because you marginal costs are 0.
One school of thought is to take the time needed to write something, pick an hourly rate of what you would have had to pay a person to write it (or use what it cost you to produce it [1]) and then divide by the 'nominal' market to get a price.
Working a contrived example, lets say you write an App all by yourself, it takes you 3 weeks and you put in 300 hrs of work over those three weeks. Now you say "My time is worth $100/hr" so you've invest $30,000 into building that App. Now if the 'nominal market' which is people that you think need this capability at any cost is 1,000 people, you might charge $30/.3 or $100 ($99.95 if you're clever) for the app. After capturing your 1000 sales you've covered your development cost and are 'profiting' on the long tail with additional sales.
The danger of course is that you can over value your time and over estimate the number of people who might want your product.
[1] Cost to produce can be tricky if you are building several things, how much of your UI design developer do you charge to one project or another? Even fractions is a common technique but the designer will tell you that some projects took more of their time than others so its not a perfect strategy.