An evaluation of software pricing models

Pricing software has always been an interesting exercise. The marginal cost to copy and provide software is virtually zero. However, the cost to develop it—and the value of the intellectual property that goes into its creation—is far greater. These two tensions have created a range of models that vendors use to price software. This post evaluates several of these, highlighting ideal (and non-ideal) markets for each.

Open Source (or “Software should be free.”) There are many proponents of this – based both on economic philosophy as well as the concept of social production. However, free software does not work – at least for anything that is important to the enterprise. It creates no economic incentives for someone to support you (through documentation, bug fixing, advice, etc.) I do not see this becoming a winning model (unless we fundamentally change our world economy to something from the UFP or Animal Farm).

Price per CPU, server, CPU cycle, etc. This model creates interesting incentives: the less scalable your software is, the more CPUs your customers need, the more they pay. As such, it only works in a few places. For utility applications (e.g., web servers, database servers) it is fine, as it encourages vendors to compete to provide the best performing utility. For enterprise applications it is terrible, as it rewards poor performing software.

Pricing per unit time. I know—this is from the Main Frame Age. However, it is coming back in some cloud computing circles. Just like pricing per CPU it only makes sense for utility applications. It does not for enterprise applications.

Pricing per end user. This model makes sense in the consumer market, as each person who uses the software pays for it. However, it is less suitable in the enterprise market. Many enterprises employ multiple people to work, from different roles, on the same process. As a result, this model requires them to pay more to perform the function they need (ultimately making the software less valuable to them).

Pricing based on type of use, i.e., pricing someone who is a service provider different than an end user. I have seen this model used on occasion in the utility space, where I pay more if I using my database to build services I sell to others vs. services I use myself. Whenever, a vendor presents me with this model, I immediately look elsewhere. If you want me to buy and use your product, let me do so. If you want to treat me as a value-added reseller, incentivise me (instead of penalising me).

“New car style” pricing. Yes, I made this term up. It is a term I use for software provides who use very complicate pricing (pricing where the sales representative has to use a web portal or spread sheet to figure out my price). This is as bad of an experience as buying a new car (and very hard to scale from sales force perspective). Keep it simple: it will make it easier for your customers to see your value.

Pricing based on value created. This is also an interesting model, where the vendor prices based on how much value it provides. Economically, this provides the potentially for the most economic efficiency. However, value can be very hard to measure – especially between two or more parties. Structurally, this looks more like a value chain partnership than a simple sale. However, a software provider occasionally makes this work; when they do, I applaud it.

Utility pricing, i.e., pricing based on consumption. This sounds like SaaS (software-as-a-service) but it is not, it is pricing based on unit of consumption. This is ideal in situations where customers can provide a value on each transaction (i.e., it is great for PayPal but terrible for Microsoft Word). It is similar to pricing on value, but prices on the process input (rather than the output) something that can be much clearer to measure.

Pricing as a tax. This model is not used much. It is basically pricing unlimited usage of software as a percentage of the enterprise’s revenue, operating budget or some other metric (e.g., headcount, payroll). The big challenge of this is picking the time interval for measurement and billing. However, it can make the value of your software much clearer for C-level decision-making.

You will notice I did not discuss the concept of on-premise vs. SaaS vs. hosting. I did this on purpose. These are delivery mechanisms, not pricing mechanisms. It is important to separate the two, as it allows customers to evaluate your software based on its value (i.e., price) and most effective means of delivery.

Authors Note: I am sure a missed many models. I encourage you to comment; not only on the above, but on items I may have missed. Thank you.