For many startups, creating a great tool or service is easy. The hard part comes when you go about trying to sell what you’ve built – not least because there are so many different ways to price a developer app or service. Identifying the right pricing strategy for your product and market can be quite difficult.
We can’t tell you which pricing arrangement is best for you, but we can offer guidance by describing the main pricing models used in the software ecosystem, the pros and cons, and some examples of companies that are using them successfully.
Subscription-based pricing is probably the most common type of software pricing arrangement today within the IT industry at large, so let’s start there.
Subscription-based pricing refers to, of course, a pricing model where customers pay a fixed rate on a recurring basis—usually monthly or yearly—for access to your tool or service. This pricing model is widely used by SaaS companies today, with vendors like Splunk and Sumo Logic being good examples, though both companies also have some usage-based fees factored into their pricing models.
The main advantages of subscription pricing include simplicity (it makes it easy for customers to predict their costs, and for you to predict your per-customer revenue) and the way it encourages customers to keep purchasing your service over a long period (because it’s easier for them to keep you in their budget when your product is already a recurring expense).
On the other hand, subscription-based pricing is not ideal for tools or services that are in an early stage of development and will add significant new features or functionality. In that case, subscription billing makes it harder to increase the cost of your product for existing customers as the product’s functionality expands. If customers become accustomed to paying one monthly or yearly fee, but you add new features and need to generate additional revenue to profit from them, you either have to raise your subscription fees (which could alienate existing customers) or keep rates the same for existing customers and raise them only for new customers (which will undercut your ability to grow your revenue).
The bottom line: Subscription-based pricing is an effective pricing technique for products or services that are already relatively mature, and where your goal is to establish a customer base and maintain the base for a long period of time. It doesn’t work as well, though, if your product is very new and your goal is to substantially scale-up revenue.
Pay-Per-User (or -device) Pricing
Charging customers based on the number of users (or devices, which is a variation on this pricing theme) who will access your product is another popular pricing approach, exemplified by vendors like Salesforce. This pricing model can be combined with subscription pricing so that customers pay a recurring fee that reflects their total users or devices. Or, it could be administered as one-time pricing, where the one-time cost reflects total users or devices.
The benefit of pay-per-user pricing is that it enables you to offer compelling pricing to customers that are both large and small, because pricing is tied to the size of the user base. A small developer team who might not be able to afford enterprise-class subscription pricing will be more likely to adopt your tool if they can pay on a per-user basis. At the same time, however, you can still charge enterprise-level fees to enterprise customers that have larger teams.
For this reason, pay-per-user pricing is advantageous if you are selling a tool or service that has appeal to a broad range of customers, especially if some of them are likely to be price-conscious (which SMBs tend to be).
The big downside of this pricing model is that it is difficult for you to administer. In order to prevent abuse and avoid lost revenue, you need to make sure your software can tell how many users or devices are accessing it, and then enforce your pricing and usage agreements accordingly. This adds a lot of administrative overhead and makes per-user pricing difficult for small vendors that lack a large sales and customer-management operation.
One-time-charge pricing – which means, as the term implies, charging customers a one-time fee, then letting them use your product or service indefinitely. This was once a popular pricing model in the IT world: Remember when you bought Microsoft Office in a box at the store instead of paying a monthly fee for Office 365?
The popularity of this pricing model has waned as more vendors shifted to a SaaS model that constantly updates instead of selling a new edition with upgraded functionality periodically.
One-time-charge pricing is still used by some vendors: InfoFlo, a CRM platform, is one example. While this type of pricing is generally not popular for startups because it doesn’t lead to a recurring revenue stream, it can be advantageous for vendors who don’t yet need much revenue and just want to expand their market share quickly. In that case, charging a one-time fee for indefinite product access can make your product more attractive than those of competitors who charge recurring fees.
One-time-fee pricing can also work well if the product you are selling is not likely to be used indefinitely or frequently. A post-mortem security analytics tool, for example, could be priced this way, because it would only be used in the event that a security incident occurs. One-time charge pricing helps make the product attractive to customers who don’t want to pay a recurring fee for a product they only use occasionally. In contrast, any kind of CI/CD tool that is used recurrently as part of the software delivery pipeline, probably should not be priced using one-time charges.
Freemium Pricing Models
So-called freemium pricing, wherein vendors offer one version of their product for free and another at cost, is also a popular approach today. That’s especially true in the open-source ecosystem, where the core open-source versions of platforms like MariaDB and MongoDB are free for anyone to download and use, but enhanced versions that offer extra features and/or professional support services cost money. Keeping this in mind, your product does not have to be open source in order to use freemium pricing; you could simply offer one version of your product free of cost, without opening up the source code, and charge for another version.
The obvious advantage of freemium pricing is that it allows potential customers to get to know your product for free while allowing you to generate revenue by offering an alternative version at cost. In a sense, freemium pricing is like advertising your product for free, using the free version of the offering.
The downside, of course, is that some users—indeed, most users, in many cases—will stick with the free version of your product, and never pay you a penny.
That’s why it’s important to be sure that you can effectively offer your product in multiple versions, and have the for-cost one deliver real and clear value before you adopt freemium pricing. The meaning of value in this context will depend a lot on which type of customer you are dealing with. Enterprise development teams that need the reliability of professional-class, 24/7 support may be willing to pay for a software package that offers that support and/or a high SLA guarantee. Smaller teams that have more tolerance for disruption may not be willing to pay for these things.
So, consider your target customers and their needs before you adopt freemium pricing.
A final pricing model worth considering is to have no fixed pricing at all, and instead to offer customized pricing to each customer. Typically, you would require customers to contact you to get a custom pricing quote if you took this approach. An example of this model in the wild is New Relic’s pro pricing plans.
There are many drawbacks to this approach. Customers may not like the lack of pricing transparency, and may not be willing to contact you to get a custom price. You also need to devote staff hours to assessing each customer and developing a pricing plan accordingly. Your revenue will also be harder to predict, and (if you allow your customers to negotiate pricing at all) your profit margin from some accounts may be very different from those for others, due to differences in pricing.
On the other hand, a custom pricing model is a great way to build a deep customer relationship from the start. Instead of simply allowing customers to sign up and start using your product, you have your sales team work with them to build tailored pricing before they even become customers.
Overall, however, the time required to administer custom pricing makes this a difficult pricing strategy to scale up. Unless you expect to work with only a limited number of high-value accounts, custom pricing is not a great way to establish a foothold in the market and grow quickly.
The software pricing models described here are by no means all-or-nothing propositions. Many real-world pricing plans take a hybrid approach and combine features of different strategies; there are subscription-based pricing models that are offered in different tiers depending on the numbers of users a customer has, for example; and per-user pricing plans where products are free to use if the number of total users falls below a certain threshold.
The lesson? Don’t be afraid to mix and match different pricing strategies to find the right fit for your product and market. And don’t be afraid to make an adjustment if the pricing strategy you adopt at first doesn’t seem to be working. Nothing in the world of software pricing is written in stone.
<div class="blog-cta"><h3 class="blog-cta-headline">Build and manage pricing plans with Manifold</h3><a class="button button-brand" href="/build"><div class="button-text">Check out the new Plan Builder</div><img src="//assets.website-files.com/5d5acff74a2e86484bb721fc/5d7bbab3af998bd22c394550_arrow_right.svg" alt="" class="icon"></a></div>