You might first think that the question is market entry strategy or business model related. It is, but it’s also more than that. Your decision affects the developer experience as well. What works with B2C markets, probably does not work in Business to Developer (B2D) marketing. Clearly developers prefer to have freemium. Freemium is not a silver bullet though especially if you consider the liability of the company.
You should not mix pricing plans to how customer is billed since for example customer may be using per API call plan, but billed once a month. Now it’s becoming more popular to have annual billing as an alternative. With annual billing you normally get a discount, but from providers perspective you have one more long term committed customer. It’s not a hard vendor-lock, but financially you will be committed to one provider for a year. Different pricing plans exists and occasionally some of them are combinations of basic forms discussed below.
The spark for this post began with the questions:
- Trial or freemium - which one to choose?
- Are there no cases for trial?
What are the above?
- Freemium, when there exists a limited basic plan and users can overtake the limits depending on they pay for the service, Sendgrid is an example here with 100 emails / day freemium.
- Trial, instead of offering contant free use, you offer a trial period (7-30 days) after which consumer either becomes paying customer or not. You need to decide which pricing plan to go after the trial.
Trial is used (in apps) mostly because conversion rate in freemium is normally pretty low, only some percents. What ever pricing plan you decide to build, make sure it does not create unncessary hurdles for the developers. I was not able to find a research on conversion rates with APIs.
A business that uses freemium invoicing API, for instance, will find that as its client base grows, upgrading to a plan that allows them to invoice more clients is only natural. The notice that they’ve run out of the invoice quota can serve as a prompt that it’s a good time to upgrade.
They need to learn first how your product works, how it can be utilized and what is the cost structure now and in the future. Lets have a look at the two models more thoroughly. After that discuss variations and combinations.
Because subscriptions are based on the association of a payment method with a plan, your customers must provide a payment method at the start of any subscription – even those that include a trial period before the first billing cycle. The day after the trial period ends, customers will be charged automatically for the subscription. Customers are not alerted by default when they enter the first billing cycle – you must be proactive to make sure your customers know that the trial period is ending and they will be charged soon.
The failure to alert the customer prior to their charge, or give them the option to opt-out, will result in something referred to as negative option billing. Negative option billing puts you at an increased risk of chargebacks, as customers may not be expecting this delayed charge.
The auto-renewal without an email asking the customer if they want to renew a particular service might be legally OK, but is it ethically OK? Who can remember renewal dates for all of our subscriptions these days? I think it’s disgraceful.
One of the customer hooking stategies in apps I’ve encountered is to offer paid service level first as a trial and then after it ends drop the user to freemium level. Provider hopes that I get frustrated with the lower level and start paying for it as a subcription. Other reason for this strategy is that provider hopes I get so accustomed to the service that I “can’t survive without it”. It become part of my daily life and I “need” the paid version. This is what Todoist does with their app. They also provide API, but it’s not sold as a product.
I would say that forget trial model with APIs - it just does not work in B2D context.
With freemium you do not get the above mentioned shitty situatons. You just use the API and depending of the service provider you might be cut off from the service for a while (before new period begins) or you might experience slow or otherwise limited service. One of the problems to tackle with freemium is that it cannibalizing paid products while acts as a magnet for leads.
One of the biggest hurdles of trials (regardless of period length) seems to be the time boxed opportunity:
Luckily freemium does not equal advertisements - at least not yet. Reqruiters are already taking the first steps to enter developer’s code domain. One of the horrible examples was to make pull request to a repository in Github:
Are we far from advertisements in API responses either?
Freemium preferred over trial
From developer’s point of view trial might be a bit problematic. If you are building a service startup style and you have difficulties to grow own paying customer count, you end up to situation in which your costs start to climb. If all the APIs you use have just trial periods, then at given moment your costs rise at one point. In other words, trial does not offer a chance to select paid plan at the right moment for me, the customer. Instead it aims to dictate the schedule and serve API owners interests.
The API consumer should be able to define exactly the right moment in time to get familiar with your product. Developer might be learning multiple APIs at the same time and for some reason not able to focus on your API with trial already activated. That kills the opportunity to learn your API without costs, which is now expected and default. Developers select not to register and activate trial at all unless it’s mandatory API and in those cases it’s a different game all together.
Somehow the trial feels like legacy which is used by business people who did their MBA in 199o’s. Good way to push customers away is to use trial period and require billing information in the first registration.
However business-wise… Jason Benkins, the founder of SaaStr, argues in this article that you need 50 million active users for freemium to work. If you bother to read the article (which most will not, just copy-paste the claim) you’ll notice that there’s a lot of clausules such as aim is 100 million dollar business to enable IPO and that it assumes “no human involvement ever”. Take a look at it and make your own judgement. As Jason points out companies have frown past 100 million with freemium: Box has grown past $100m in revenue, EchoSign, passed the first $10,000,000 in ARR revenue, DropBox is past $100m on Freemium… But since business is not the core of this blog series I will not go any deeper into this.
Pay-as-you-go, when a customer accumulates a monthly bill basing on what is its use of API resources. Example is F-Secure Security Cloud API for URLs, in which customer pays $0,003 /request. Previously mentioned Amazon Web Services are operated with APIs, but you are not charged (or paying) for API usage. Instead you might be using S3 to store, manipulate and retrieve data. In that case storage is what you pay for, not the availability or use of API. There is now base fee or other costs, you pay for what you use.
From API consumer’s point of view this pricing model is tricky since it makes hard to estimate cost structure. Developer has to build cost management in application/service to avoid situations in which costs can rise too high. This is not a big problem is the application is commercial and it has paying customers. This is a big problem if it is freemium and the amount of users skyrockets in one night.
In some cases freemium and pay-as-you-go are bundled so that to a limit you can use the API for free, but after that you pay for the usage until the period resets.
Tiered or fixed quota
Tiered or fixed quota, when each tier has its own set of services and allowances for access to API resources and it is fixed a prize for each tier. Pusher for example has four paid plans ranging $49 - $499 per month.
Pusher does have “sandbox” plan as well, which is freemium plan discussed above. This freemium is good for experimenting with the service. You most likely will get only limited support (but same documentation as paid customers), but you are not forced to buy the service without seeing it in action. Freemium enables developers to test if API will provide enough added value for the price.
With the fixed tiers big question is what happens if the API call limit is reached? For the API consumer (app developer) this is crucial since if the API just stops responding then application end-user experience is ruined. Regardless of the plan that is not good situation, but more acceptable with freemium plans than with paid plans.
Standard solution is to put additional cost per exceeding API call in the fineprint. This resulting model is called overage model. The overage model has advantages since it contains the scalability of pay-as-you-go model and predictability of fixed quota plan. In addition, application consuming you API never shuts down. This is why overage model has become one of the popular options.
Unit-based, when pricing is based upon a pre-defined unit of measurement, such as API calls or the storage used on disk. Instead of paying directly with credit card as euros or dollars, you pay with units. You can purchase units or credits with money.
Enterprise pricing, when pricing is part of a larger sales process, it is a common way for large companies to price products and services based upon customer’s needs. For example Pusher offers custom plans for customers which need more than 10 000 concurrent connections.
Volume pricing, when pricing is based upon volume purchases by buying in bulk, e.g. MailGun defines an initial price of $0.00050 for first 500,000 sent emails and $0.00035 for the next 1,000,000.
Bundled, when your SaaS service is GUI driven and API is offered for paying customers to enable automation and easier integration to other systems. The same situation applies to hardware driven products as well. If you buy Polar sportswatch, you can access your training information with the API.
The above are probably the most common pricing plans, but it’s not all-inclusive. At this point you have developers needs and desires fulfilling pricing. Next question is the quality of your API and then your eyes are turned towards SLA.
Some more to read from 100 Days DX
- #85 - Great Developer eXperience requires fluent internal workflow
- #84 - Theory of Economics of Developer eXperience
- #83 - The Space of API Design Decisions is missing
- #82 - Purpose of API Evaluation Framework
- #81 - Should We Move to Stack Overflow?
- #80 - Four data driven ideas for improving API documentation
While you are here...
Check out Platform of Trust in which I've worked to enable best possible developer experience!