Pricing for software is both an art and a science. In this post we review the common scenarios that platform teams have to think through, when deciding how to price their platform.
Start with the outcome: a delighted customer
Before going into strategic and tactical pricing topics, start with a vision. Why are you bringing a software platform to market? How will it be differentiated relative to existing players? Because major technology companies already have application development products in market and at scale, your product needs to stand out with an ability to address a specific customer segment, or provide value not found elsewhere, or compete on costs, which can be challenging.
A delighted platform customer builds its intellectual property (IP) on top of it. This is the first thought process to conduct: how will the customer find it uniquely useful and innovative to build on your product?
Once you have this customer experience in mind, consider the second factor. If your customer can build enough financial value with their IP, how you price your product only becomes a matter of how it competes in the market. In other words, if you provide a differentiated platform and enable the customer to price their product high, pricing will become a small cost of goods sold for the customer.
Understand your cost model
Computing as a utility, which can be consumed and paid for just like electricity, was a concept for a long time. One of the key challenges to make the vision a reality was solving the cost model. How to track compute usage, bandwidth, storage, by the second, for each platform user, and accurately bill the user for it?
Understanding the cost model is crucial to create a predictable and eventually profitable business.
Understand the usage pattern of your customer applications
In order to come up with a simple pricing model for your platform, it is advantageous to come up with the top usage models and patterns. By doing this, you can adapt pricing to a few scenarios that are known and repeatable.
Some platform providers place limits for certain metrics. For example, your pricing plans may include storage, but with a certain maximum limit. Once that limit is reached, your customer can purchase additional amounts on top of the current plan. Other companies place soft limits in their contracts. They do not put a technical blocker, but ask that customer adhere to the limits contractually. It is easier to implement from a technical standpoint, while harder to enforce.
Pricing per resource
Today, much of the cloud infrastructure business, also known as Infrastructure as a Service (IaaS) prices per resource. Because the platform services provide the lowest level of abstraction (CPU, bandwidth, storage, etc), it can make sense to price by usage. This is the utility model, like electricity.
Pricing per resource can also make sense for customers exceeding limits in a particular non-resource plan, such as a per user or per application pricing model. These fees come on top of the bill, and are straightforward to itemize and account for.
Pricing per resource can also come handy for data-centric platforms. If you are selling statistical data in certain amounts, and that an increased quantity provides more value to your customers, using resource pricing can make sense. However, if the amount of data does not correlated with the level of customer value created, a different model would likely work better.
Pricing per app per user
The user pricing model tends to be popular for higher level platforms, for example the declarative application development tools to build workflow apps. When dealing with business applications, many of them to this day have been based on workflows: stage 1 of a process, the user does a, b and c. Then it moves to stage 2 of process, where other users may do d, e, and f, and so on. These workflow applications tend to revolve around named business users, and generally not vary widely in the compute resources they consume. Hence, pricing per user for these scenarios makes sense, with higher tiers in the event of extra features needed, and then limits above these tiers.
When pricing per user, customers and platform providers often need to discuss the case of infrequent users. Some may use the application daily, and see the value in paying full price, while other users may only use it once a month, or two weeks per year. It is the role of sales to determine what makes sense based on the specific customer scenario.
Pricing per user also makes sense in the broad context of applications destined for internal use. If a customer creates a sales application to be used by their internal sales operations team, there will be no reselling, no distribution
Pricing applications as a percentage of revenue
Finally, some software platforms offer pricing as a percentage of revenue. Distinguishing from the model in the previous section, this pricing strategy applies mostly to independent software vendors (ISV).
An ISV builds and application on a platform, then distributes the platform plus its intellectual property, i.e. its application code, to downstream customers. For the cloud, ISVs are in essence value added resellers (VAR). In the previous generation before the cloud, VAR companies would resell CDs and license keys under one contract. Cloud ISVs do this by embedding web services and building on top of one or multiple platforms.
Pricing as a percentage of revenue has its own requirements. For example, the platform provider will need to ensure that partners do not game the system by pricing their application at $0.001 per user, effectively paying nothing to the platform. To remedy this, it can make sense to include a minimum per user pricing, i.e. a floor that the end customers must pay for the partner application. This ensures fair pricing for the customer, for the ISV, and for the application platform provider.
Leave a Reply