If you are a solo developer, or have a leading role in a software company, you might have to decide how much your software will cost one or another day... What is your experience with calculating how much your software costs for your customer? Why does this method it work for you?
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
|
|
|||||||||||||||||
|
|
Neil Davidson wrote a free eBook called Don't just roll the dice - a usefully short guide to software pricing |
|||
|
|
While I don't agree with everything Joel says, his "Camels and Rubber Duckies" article on this topic is a must-read, IMO. The basic advice is "charge what people will be willing to pay", or:
|
|||
|
|
|
Another way to look at this is "what software gets ripped off the most?". The high-ticket software like Adobe Create Suite is often a target as the initial price is just so high - several thousand dollars for a massive package of which you may end up only using 10% of the capability of each component. Look at the effort that Microsoft has put into their 'Genuine Windows' initiatives - does anybody actually buy Windows or Office any more? The businesses that get audited have to, but many small businesses and huge numbers of home users seem happy to use an illegitimate (or illegal) copy. My personal opinion is that if you want to make some money from your software, do not release the source code into the public domain/open source community. There clearly are cases where selling support for an open-sourced code can lead to profitability, but IMO opening up your source code should be done to get community input. Exposing your cool code to the web loses your competitive advantage if you want the software to become a source of income. So the current best strategy for software that I've seen is to license it. Give a somewhat limited version of the software away for free so that the user can get familiar with it without having to sign up for an account or hand over credit card details, both of which are off-putting. Once they reach a point where they are using it seriously, you can offer the option of increasing storage/bandwidth/capacity/capability#. Many online services are using this model as are iPhone apps - download 'lite' version for free, pay to activate more features. The actual price for which you license the software is a factor of:
Examples:
# If paying unlocks some capability, don't put that capability in the free version as it will get cracked - regardless of how much market penetration you get. There are some people who just love to subvert software protection mechanisms and several of the products I've worked on over the years have had this fate - even the niche stuff. I'm no expert, but a combination of a uniquely-identifiable downloaded version that can be black-listed if it 'calls home' from more than X different IP addresses may be a starting point. If you detect someone has been handing around their copy of the software, you have a few options - talk to them (if they are registered) as there may be a good reason (they reformat their PC regularly, etc), close their account (with notification as to why) or bill them accordingly if you have their credit card details (but expect recourse from this action). |
|||||
|
|
Figure out your pricing objective first. Then look for pricing strategies to achieve that objective.
|
|||||||
|
|
You need to work out how long you think it will take and how much you want to earn per hour and then times one by the other. Next you need to add in any costs you will incur in writing the software. Then you need to add in any contingency... i.e. if you are doing fixed price work, what are the chances of something cropping up that will take extra time. Lastly, you need to make sure that your cost is printed on the same piece of paper that states exactly what you will deliver in exchange for the money and you need to take a deposit... you will prevent a lot of time-wasting by insisting on a deposit. |
|||||
|
|
I actually wrote a couple of articles on the subject a few months back, but just stumbled over this question now. The easy way out is to say it differs a lot depending on target audience, market, size of problem solved and so forth, which is all true - but I think you can divide software to 3 general categories:
Assuming you don't fall in the 3rd category, you need to figure out in what category are you. Nice-to-have software should generally be priced in the range of "why not?" (as Jeff calls it in his article), which means low enough that that a potential client doesn't mind opening his wallet, while must-have software have much more flexibility with the pricing. What makes software a must-have? that's where all the different variables come in to play. The most important ones in my opinion are:
When I price software, those are the main considerations I take. You can factor in additional parameters, such as market (you can price higher when selling to the enterprise as opposed to the private sector, for example). Also, never be afraid to experiment after you set the price. Give some time for data to accumulate and try to test different pricing to see how it affects sales. |
|||
|
|
|
Keep in mind that your price also will reflect the quality of your software in the eyes of potential buyers. There is a psychological effect that if product A is priced higher than product B, product A will be seen as higher quality than B even without any supporting information. This is true from canned beans to cars to houses. Ultimately your business case for this software will define your price point (is this a one-off, extension of something existing, a loss-leader to gain new customers? etc.) |
|||
|
|
|
Don't charge - release it as Free/Open software. Then provide way for people to donate whatever they like, based on how useful it is to them. (Unfortunately, I don't actually know how effective this is.) If this is a core product for your company, you can still do the above, but also a commercial license and support contract, and maybe sponsored feature development too. |
|||||||||||
|
