When the founders of a software company, come up with an initial idea, they rarely put much too of an effort on how much their software should eventually cost… This might seem counter-intuitive or even absurd, but in the very initial phases, founders typically focus on
- developing and
- marketing the product.
While pricing is obviously an integral part of marketing, especially in B2C scenarios, pricing is often considered as something that can be “figured out”, once the demand is there. In addition to this, things get more blurry in B2B scenarios, where pricing can be very custom.
This article tries to demonstrate the distinction among two concepts/terms that are commonly used interchangeably when discussing software licensing: licensing model and pricing model, or the difference between identifying your pricing blocks and assigning a price to them.
For software vendors, this distinction is crucial in order to
- understand what kind of internal systems are required in order to achieve market flexibility, i.e., the ability to quickly test and adopt new licensing and pricing models.
- which departments and how are involved in the definition of licensing and pricing models.
For simplicity, we are going to use a desktop application as a reference. But the same principles (with slight variations) apply for web, SaaS or mobile applications, either B2B or B2C.
LICENSING MODEL
Software licensing models typically involve some (or all) of the following entities:
CLIENTS: USERS AND DEVICES
In most cases, this is the most fundamental licensing entity:
- Devices (e.g., hardware, IoT, smartphones) or/and
- Users
Using our sample desktop program as an example, a device license indicates that the software can be used on a single device.
Further licenses are required for use on additional devices.
A user license, on the other hand, allows an authenticated user to use the program regardless of the device.
The term (license) seat is commonly used in this context.
PROVISIONING MODE
In B2B scenarios, where multiple license seats may be involved, you need to decide if entitlements are:
- Named: the most common provisioning mode, means that n clients (devices or users) require n licenses.
- Floating (concurrent): In this mode, n license seats allow the simultaneous operation of n clients (users or devices).
The n+1st client is unable to use the software until the nth client disconnects.
FEATURES AND LIMITATIONS
Another key consideration is to whether and what kind of functional or non-functional limitations need to be enforced (obviously for targeting different market/price segments). This is typically achieved by defining
- Features (on/off functionality)
- Limitations (quotas)
SOFTWARE RELEASES & UPDATES
Desktop applications can impose an extra limitation type on software releases (and upgrades). For example, the licensee is allowed to perpetually use software version X, but not Version X+1.
PRICING MODEL
There is no shortage of creativity when it comes to pricing models. Essentially, all components of the licensing model, such as devices, users, features or limitations can be priced separately, collectively (edition) or in some kind of combination. Therefore, pricing models may (but should not) grow quite complex. Without going into too many details, these are 3 areas to consider:
EDITIONS AND ADD-ONS
Editions are an excellent tool to simplify things, for both software vendors and licensees. Defining editions is very straightforward. An edition can contain any components of the licensing model. As soon as a licensee requires a feature that is not included in his/her current edition, an upgrade is necessary (even if the upgrade includes many more elements that are not necessary).
Of course, you do not have to work with editions. In this case, every component of the license model is priced separately, resulting in a completely individual configuration for each customer.
A hybrid approach, is to begin with editions, and price certain features or limitations separately on top of them, commonly referred to as add-ons.
When all (or a subset) of these components are combined, your licensing model may be named user, or floating devices, with or without features, limitations. It is essential to highlight though, that the licensing model does not include any price considerations. Which brings us to our next point.
PRICE
The price of an edition (or an add-on) may be fixed or consumption-based, with consumption applicable to any component of the edition. A combination of fixed and consumption-based features is certainly plausible. For instance, the price of the basic edition may be
- 30€ including 3 users
- 10€ per user (with maximum 5 users)
- 30€ including 3 users, and 5€ for any additional user (with maximum 10 users)
FREQUENCY
Although subscription based pricing is becoming the standard, especially for B2C applications, there are still plenty of (mostly B2B) applications based on a one-time upfront purchase (plus a yearly fee for support and updates).
These two models can coexist, meaning there is a one-time fee in addition to a subscription component.
IMPLICATIONS
Regardless of the language, software vendors must be able to rapidly adapt to shifting market conditions, i.e., provide what the customer requires.
LICENSING SYSTEM
After defining an initial license model, and assuming that software audits is not a viable solution, the model must be technically implemented, i.e., it must be incorporated into your code base. While it might be tempting to let your inhouse developers do this, using a software licensing api instead, does not only simplify the whole process for all departments involved (business, development, engineering), but it is also a much more cost-effective long-term strategy. Such a professional software licensing solution enables you to:
- define and adapt everything we described as licensing model
- define and adapt editions and add-ons as described in the pricing model
The most important notion in this context, is the ability to adapt. Yes, your engineers have to indeed implement the initial integration. However, after this one-time step, your product management should be able to change or offer a new edition, within the software licensing solution, in a matter of minutes. Your application’s source code is unaffected, i.e., your engineers do not need to take any action.
PRICE AND INVOICING SYSTEM
Prices and frequency are not handled by the licensing system, but by your payment/invoicing system instead.
DECOUPLING YOUR SOFTWARE CORE FROM LICENSING AND INVOICING
In other words, you can reach the ultimate goal of decoupling your software core from licensing and invoicing.
