Good evening, fellow readers!
Yesterday, I finished a large commercial application and finally launched it. I spent about a month developing it, and then a couple of weeks setting up a website, testing payment methods and so on. As of yesterday morning, there was only one decision I still hadn't made - how much should I charge for a licence? I didn't want to make it so expensive that no one would buy it, but I obviously didn't want to underprice it either. Now, I may be wrong, but perhaps the decision would be easier if the application was targeted at a consumer market (it is not).
As an economics major, I knew the basics. However, that does not help much because, a) software is different from other products due to the fact that it does not have any variable costs (i.e. creating one instance of the application costs me the same as creating ten million); and b) economic theory works best when your customers are perfectly rational decision-making robots (which, I assume, my customers are not). So, naturally, I had to do some research.
Unfortunately, no source told me how much my software should cost. However, there was some advice, that I found useful. Here it is:
1) Perceived value is not the same as objective value
From a logical point of view, if a product saves you 5 hours of your time, and you value your time at $20 per hour, you should be willing to pay anything under $100 for that product, assuming you have nothing better to spend that money on. However, how many of you actually make such calculations? For most people, purchasing decisions are made based on the perceived value of a product, which can be influenced presentation, marketing pitches and testimonials - and, surprisingly by the price.
2) The price sends a message to the customers
A product for $10 is perceived differently than a similar product for $100. Underpricing software is dangerous not only because it can decrease revenue, but also because it can trick customers into thinking that the application is useless or low-quality.
3) The product is more than the product
People pay for the experience of dealing with a business, not just for the software itself. So, the price should depend on the objective reality of the whole operation - starting from the marketing pitch and finishing with the support that is provided.
4) Price tiers help - but at a cost
By offering several price packs, not only do you give the client a choice, but you also provide a point of reference (also, importantly, one that does not involve looking at the prices of competitors). However, multiple prices mean more complexity for the marketing, a more complicated support infrastructure and, potentially, more confusion for the clients.
All in all, choosing the price is still no easy endeavor. Fortunately, as with most things, you can test different options and see what works best. I have decided to go with A/B testing, where several groups are made the same offer at a different price to see which responds better.
Yesterday, I finished a large commercial application and finally launched it. I spent about a month developing it, and then a couple of weeks setting up a website, testing payment methods and so on. As of yesterday morning, there was only one decision I still hadn't made - how much should I charge for a licence? I didn't want to make it so expensive that no one would buy it, but I obviously didn't want to underprice it either. Now, I may be wrong, but perhaps the decision would be easier if the application was targeted at a consumer market (it is not).
As an economics major, I knew the basics. However, that does not help much because, a) software is different from other products due to the fact that it does not have any variable costs (i.e. creating one instance of the application costs me the same as creating ten million); and b) economic theory works best when your customers are perfectly rational decision-making robots (which, I assume, my customers are not). So, naturally, I had to do some research.
Unfortunately, no source told me how much my software should cost. However, there was some advice, that I found useful. Here it is:
1) Perceived value is not the same as objective value
From a logical point of view, if a product saves you 5 hours of your time, and you value your time at $20 per hour, you should be willing to pay anything under $100 for that product, assuming you have nothing better to spend that money on. However, how many of you actually make such calculations? For most people, purchasing decisions are made based on the perceived value of a product, which can be influenced presentation, marketing pitches and testimonials - and, surprisingly by the price.
2) The price sends a message to the customers
A product for $10 is perceived differently than a similar product for $100. Underpricing software is dangerous not only because it can decrease revenue, but also because it can trick customers into thinking that the application is useless or low-quality.
3) The product is more than the product
People pay for the experience of dealing with a business, not just for the software itself. So, the price should depend on the objective reality of the whole operation - starting from the marketing pitch and finishing with the support that is provided.
4) Price tiers help - but at a cost
By offering several price packs, not only do you give the client a choice, but you also provide a point of reference (also, importantly, one that does not involve looking at the prices of competitors). However, multiple prices mean more complexity for the marketing, a more complicated support infrastructure and, potentially, more confusion for the clients.
All in all, choosing the price is still no easy endeavor. Fortunately, as with most things, you can test different options and see what works best. I have decided to go with A/B testing, where several groups are made the same offer at a different price to see which responds better.
