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?

@Pierre303: I initially felt the same as you, then looked at a ton of other questions here and actually there are very few that get accepted. When the question invites multiple answers, there is often no 'best' answer to accept, only the most popular, due to up-votes. This is very different behaviour to SO, where many questions are seeking a single 'correct answer'.
–
JBRWilkinsonOct 5 '10 at 8:59

Can you clarify the question: are you asking about how to decide cheap/expensive software should be, or how to determine what the outlay is to complete a project, or something else?
–
Peter BoughtonOct 5 '10 at 11:37

It's indeed about the software, not the project.
–
Tom WijsmanOct 5 '10 at 14:21

I also recommend this book. While it doesn't give you a specific rule or formula for determining how much to charge, it mentions most potential avenues for charging and how to set the price. In the end, you're still going to have to name the price yourself though.
–
mbillardOct 15 '10 at 13:05

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:

purpose - how hard is the task it solves?

target market size - how many people are face with this issue?

market segments - are there different levels/types of user in this market? (power users vs home users, etc)

# 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).

There are several different business models for people to use Open Source/Free software they developed. One is to charge for support, dual licensing is another, and both have been used by profitable companies.
–
David ThornleyOct 5 '10 at 21:46

Figure out your pricing objective first. Then look for pricing strategies to achieve that objective.
- Survival? Then set price levels to match expenses.
- Maximize Profit? There are many strategies to consider, e.g., "Price Skimming" like Sony did with the PS/3, works if its legal in your jurisdiction and if you face an inelastic demand curve. Sony set prices high initially $599, and gradually lowered them to $299.
- ROI? Set price levels to get back a certain annual return on equity.
- Increase Market share? If your demand curve is elastic, lowering prices relative to competirors may help achieve this.
- Cash flow? Price levels should encourage rapid sales.
- Status Quo? A price war may be unwinnable. Don't rock the boat. Set prices to match your competitor's prices.
- Product Quality? Set prices to recoup R&D costs and to establish a high quality image.

The other price skimming technique is different versions. The PS/3 today is not actually the same as the original, having lost some capabilities along the way. Book publishers put out an expensive hardcover version first, then later a less expensive trade paperback, then an even less expensive mass-market paperback, to collect the premium from people who won't wait and still let them feel like they got a better product.
–
David ThornleyOct 5 '10 at 21:49

@David Thornley: Great comment. Definitely applicable here. E.g., there are six different "editions" of Windows Vista out there (Starter, Basic, Premium, Business, Enterprise, and Ultimate) times two (32/64-bit). All priced differently.
–
A. N. OtherOct 5 '10 at 22:30

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:

Must-have software

Nice-to-have software

Nobody-needs-it software

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:

How big is the problem being solved? How much time / money are you saving the end-user? (time = money)

How unique is the solution? (i.e, can you just find a cheaper / free / better alternative by googling for it?)

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.)

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.(This model is used at big software companies such as JBoss, MySQL, but smaller companies such as BlueRiver or Railo Technologies also do this successfully.)