Nine software pricing models evaluated

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.

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

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

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

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

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

6. “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.

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

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

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

Post Topics:
, , , , , , , , , , , , , , ,

Comments

  • Nice article, fairly covers everything except for Free and Open Source could two separate classification. Or rather replace open source with Free as lot of open source products also available at a cost – just that the source is open.

    As far as SaaS business pricing model is concerned I wrote up: Pricing your SaaS application that focuses on existing pricing models and their rationale with examples.

    Shalin Jain3 August 2010
  • I forgot to add the 10th Model: Lifetime Perpetual.
    This model is less frequent in the enterprise world (used mostly by firms who want quick revenue recognition). You pay once and use if forever. This is excellent for products that are simple and do need ongoing support or upgrade. Most major enterprise applications or infrastructure fall outside this category. SaaS should never be used here (I saw it used once in the B2C SaaS space — much to the loss of the company that used it).

    James Haughwout26 September 2010
  • We are now in first steps of trying out different pricing models for software (designed for financial sector) and as we still have big portion of budget coming from adjustments to specific back-office and business rules this is a bit of challenge. Now we try to use kind of tax based pricing – customer pays % from turnover generated with system (as system is supposed to generate more sales this is easy). Problems arises with new functionality and evaluation of value that it will bring to adjust %, but still it is very interesting process.
    For simplicity to customers we say this is SaaS, as in reality is not – this is very good point that pricing and delivery is totally different things.

    Uldis25 October 2010

Share your thoughts