If you read the book “Subscribed: Why the Subscription Model Will Be Your Company’s Future - and What to Do About It” you will be told that subscription is the only viable option. The book is great, but still pay as you go is an option when it comes to APIs. Why? Is it really so? I started to ponder this question when I was thinking about data products in Platform of Trust. The business model affects things here and there in the 360 DX piechart model.
You pay for the access - subscription
Subscription is the best option for API consumer if you know you will be calling the API frequently. In the subscription you are not paying for the data or functions per se. You are paying for the access. It’s all comparable to the setting laid out in the book mentioned above. People do not want to own nowadays. They prefer to buy access to services and goods. The reason for companies to embrace subscription business model is explained well in the book by Tien Tzuo
Cars are pooled more and more. You don’t buy books as much as you did before, instead you buy access to pool of books (Bookbeat, Storytel). You don’t buy records of some favourite bands, you buy access to pool of music (Spotify, Amazon Music). You don’t buy DVDs, instead you buy access to pool of movies (AppleTV, Netflix). The examples are endless stream.
Hell, I could subscribe to diapers as a service! Or get the electric scooter as subscription (that is now pay as you go). My wife has a vacuum cleaner (for smaller cleaning) and that still uses the bags to collect dust. We get new bags automatically - yet another subscription. Even the cleaning lady that arrives to our house every second Friday is a subscription service. Our life is filled with subscription nowadays. We are brainwashed for subscription.
It’s pretty easy to get into “subscription-lock” which can be compared to vendor-lock. Lets say you get for example Spotify and start using if your self. Your happy with it and recommend that to your wife. She and 3 others in your family want the paid plan to avoid advertisements. You pick the family package. Then your wife and some of the kids start to use it.
Now wait a a year and then suggest your wife to switch from Spotify to another service. Guess what is the response? She has created tons of playlists and it’s part of her daily life. It’s not that simple to switch anymore. For vendor this is a good thing. Your customers are hooked and it’s hard for them to jump into competing platform.
The same works for the APIs. Once you have selected some streaming API and have taken it into use with multiple apps, it’s getting harder to switch. Unless you have been wise and made a own API in front of the streaming API and your apps never call the 3rd party API directly. To replace the streaming API you still have to find another API with pretty much the same content or functions. Or make a mashup API if you need to use multiple APIs to replace that one. Weather APIs are a good example. There’s plenty of them and you can get pretty much the same from those. In those cases you can change the data stream provider relatively easily. Competition works for the benefit of the consumer.
Match made in heaven
It’s not rare that business and technology are not in sync with each other in companies. The two layers often speak different language and approach the problems from different angles. Subscription seems to be match made in heaven:
- In business model subscription model is embraced by the business developers and consumers
- Developers like to get data pushed (subscription to data) with websub and alike technologies
With subscription you can have both traditional “pull” kind of access to data. In case of REST API you can call the endpoints for given amount of times per month. Even here there’s differences what happens after rate limiting hits the breaks for your usage. Some block you, some lower the response speed, some have added pay-as-you-go type of fees for the excess API calls before the reset moment.
IF you are providing subscription (websub and alike) to data as well, then you can push the updates to clients. Putting some kind of limit there is an option as well. IF you do, you need to decide and communicate to clients what happens after the rate limit has been reached.
What else do you want?! We’ve got the killer combination now. Still the pay as you go has it’s strenghts in the eyes of the consumers.
If you are not massively and frequently consuming the API, you don’t want to pay monthly fee. You want to preserve option to use it occasionally. Then you make the account but call the API as needed.
An example would be company info API. You might want to check subcontractor details from public registries occasionally. You would not want in all cases to get updates of all companies in the registry, you want once in specific moment info for just that one company. Or to check the reliability of the subcontractor from Suomen Tilaajavastuu’s Luotettava kumppani API. (“Trusworthy partner API” my own free translation). The previous API is open data API in FInland but the latter is commercial API.
With this business model, the consumer is not paying for anything else but the actual consumption. There is no idle time you pay for which is the case of monthly subscription.
To decide to use just subscription model with you API would leave some of the customer unsatisfied. But then again, you might be happy with the percentage you get without including pay as you go in the model. The thing works otherway around as well. Forcing customers to monthly subsciption model even though they need it just occasionally most likely would scare away some of the customers.
Pay for the access
This reminds me of the VPI - value proposition interface (by Amancio Bouza). What the API product masters like Bouza say is that “It’s not about a programming interface of an application, no it’s not. Actually, an API is an interface to a value proposition!”.
Likewise I say that
You don't pay for the data, you pay for the access.
Which makes me think that we are on the same track with Amancio here. Amancio talks about the application and I say data. You pay for convinient access to data and functions. Which makes more sense to the clients, subscription or pay-as-you-go, depends of the case. Especially with subscription you are paying for the 24/7 possible access to data for a often fixed monthly price.
Some more to read from 100 Days DX
- #100 - The biggest open resource on Developer eXperience so far
- #99 - Hackers - the top 1% of engineers
- #98 - Invalid Open API spec files ruins the developer experience
- #97 - Lightweight API evaluation framework
- #96 - Embracing open source community driven tools development
- #95 - Exploring the multilevel nature of API Design Guides
While you are here...
Check out Platform of Trust in which I've worked to enable best possible developer experience!