More information needed. $1 / call might be a deal if that is actually a savings over an alternative means of achieving the outcome. Or, $30/mo might be a real bargain for the consumer but a terrible business model for you. Also, depends on the target buyer and their expected usage.
Depends on the service and availability. Look at Mailchimp for their options. Especially buying credit is always useful. If you need to charge them at the end of a period, you will lose money.
Generally I prefer flexible pricing, since we might need to scale up - i.e. if we double some limit, I want to be able to pay $60 rather than be blocked.
Some other considerations:
1. Have a free tier to let developers play with your API. i.e. first 1000 calls per month are free.
2. If you do variable pricing, let people set a limit and alert them before they hit that limit.
Depends on whether other people control how often I call the API. Is it a scheduled task I run? Then I'd rather pay $1/1000. Is it a trigger that fires when a new user signs up for my service, or sends a link? I'll take the guaranteed flat rate.
At a very high level —- I’m willing to pay a premium for a service at any reasonable cost, and if my business is dependent upon it. Metered use encourages consumers to be more mindful of how they use APIs. Monthly fixed fees help consumers to forecast spending more loosely; however, as a business that is depending on your service, I am also concerned about your operational scale (all you can eat is great until too much has been eaten by the aggregate customer base).
As most others will probably say: it depends. If your service is a commodity that I can switch out for another service easily, perhaps a fixed monthly fee is the only way to go. But if it’s a very unique service, metered may be the way to go.
I've worked on a lot of API integrations and $1 for a single call is way more than I've ever paid. At that price, I'd burn through more than $30 on the first day just by testing out the integration.
Heh, I misread that. But I think that's still expensive. For example, the Google Maps API gives you 25,000 free calls per day and charges 50 cents per 1000 calls after that.
While he's suggesting $1 for 1000 calls, I find it interesting to suggest $1 per call for "anything" wouldn't be worth it... for example would you pay $1 to pull someone's credit report? (not that you need to, but just as an example where $1 per API call would actually be cheap).
Agree very much here. I would argue I'd even pay more per API call versus pulling someone's credit report through traditional web app/fat client methods, as they business value is in the machine processable format.
The trick is to align your pricing with the API consumer's value received. You want a piece of their take for the value you're delivering.
I really love the Twilio model personally. I've got a system that is pretty seasonal, and it costs $10/mo for the DigitalOcean VM and pennies/mo (+$1 for the number) most months for Twilio. Around holidays and long weekends, the Twilio costs ramp up quite a bit (I think it hit $100-200 in a weekend once), but it's fine because that's when it makes money.
Only having to pay when we use it helps keep the overhead down dramatically. I've never considered looking at other options because it's been great.
For developers, too, I think the pay-per-usage or fixed-monthly model works well when it's something that they can tangibly understand. Looking at my example above, I'm fine with the fixed monthly DO cost because I know that there's some fraction of some real computer "out in the cloud" that is reserved for me and that is running my code continually. I also know that Twilio has a finite number of phone numbers available, and $1/mo to reserve one of those makes sense to me. But I also know that the way most telecom agreements work is that they bill based on usage, so me getting charged based on usage works fine for me. If they wanted to charge me $20/mo for a number even if I had not sent any messages at all, that'd be harder to swallow.
Edit: also, it probably depends on whether you're selling to small businesses or enterprises. My experiences with enterprises is that they seem to prefer having fixed costs even if it ends up costing more. Seems like it has to do with how budgets and funds get allocated. "Our SMS sending costs went up by a factor of 100 because it's Christmas" doesn't seem like something that flies very well, even if the pay-per-usage model averages out lower over time.
Without going into too many details, it's a customer loyalty and retention product. Small businesses use it to keep in touch with customers who have opted in. They seem to be pretty bursty about when they use it :)
Because it's an API and I'm a developer and a fully developed adult with several decades of computer, internet, and professional working experience in tech.
Both. I’d pay per 1K API calls below a certain threshold but the peace of mind that if I get sudden spike (or make a mistake) it’s not going to bankrupt me.
There's a rule that's relevant here: innovate the product or the pricing, but not both.
So if you're innovating on the product.. market the innovations to your users, and focus their attention on the benefits of your innovations. They should be big, obvious improvements--think 10x (not 10%). For pricing, copy it from your competitors.
If you're innovating on the pricing, then that's frequently a freemium model... but it could also be flat-rate pricing, etc. To build a foothold in an existing market, you'll need to aim for pricing that's 1/10th of your competitors. If you're going to deliver a big price cut like this, you should make it as obvious to your customers as you possibly can.
So the answer to your question very much depends on your strategy, but also the industry you are in and how your competitors price their products.
Perhaps the worst thing you could do is both... since innovations cost money and price cuts cost money... it's a great way to die. Doing less of both just creates a mediocre product without clear marketing; making it more complicated for your users to understand the benefits of your service.
Thanks for replying. To give you some context the API is ipdata.co pricing at ipdata.co/pricing.html I've gotten feedback from multiple users that my pricing is overwhelming. The API is pretty much feature complete and my main focus right now is selling.
- Your index page is missing. (I can't see your marketing angle.. so I'm not going to comment on the actual pricing... let me know when you fix it)
- you're following a freemium model, but it's not obvious enough. The first plan on the pricing page should say "FREE". Your index page (which I cant see), should say free signup & no credit card required.
- That's a lot of plans. Compare to Maxmind, they have 3 plans depending on what data you want (Country, City, Insights) + a free trial.
- In the faq, it says I need to email you to update my credit card or change my plan. I guarantee you some user will email you their credit card number. This should all be available from their account without emailing you.
Please follow this link https://ipdata.co/ the site is up, just checked.
What I do is ask the user to sign up for the new plan and refund them on a prorated basis for their usage of the first.
But good point I should make this more clear in the faqs.
I'm looking to either cut some of the plans or move to cost per usage, maxmind offer downloads of their data. If I remember correctly their webservice is charged per request but is way more expensive compared to my fixed plans. Whereas I charge by based on an API usage bucket.
Not up... content says "Page not found. Sorry. That page doesn't exist." has a blue button "RETURN HOME". Status code is 403 - permission denied. Here are the response headers:
age:267
content-length:1879
content-type:text/html
date:Sun, 04 Mar 2018 20:28:28 GMT
etag:"12ccf5f30d33b193fec3a71a4c5529e2"
last-modified:Thu, 01 Feb 2018 00:46:26 GMT
server:AmazonS3
status:403
via:1.1 7fd13f5c4b32635feca1c61001387a16.cloudfront.net (CloudFront)
x-amz-cf-id:eE3tjl3Dx6V32_J2s1k1cO1z_d5bu5sZClNZFTvkuugMGWngdtEK5w==
x-amz-error-code:AccessDenied
x-amz-error-message:Access Denied
x-amz-version-id:null
x-cache:Error from cloudfront
I'm able to see it now. It seems like there's some work that needs to be done whether or not the pricing model needs to change.
Prorating the first month is ok.. but it should be something obvious for the user. Days left in the month is frequently used, and something you can calculate up front. Which means you won't need to issue a refund later. This (like changing plans and credit card numbers) should be built into the signup/account.
If your plans are cheaper than maxmind, that's not obvious at all. Simply because your plans do not follow the same model as maxmind, and to find out if they are cheaper, I would need to convert them manually to the same units. That could be made more obvious.
I don't think the free plan is obvious enough on the front page. The "Purchase a plan" subtitle under the "See the docs" button could be "Signup for a free account". (Edit: Consider adding a free account so users already have data in your system, and just need to upgrade to a paid account. This will also give you email addresses to market to.)
Am I right that the only way to signup for a plan from the front page is to click on "Pricing" in the header or the small subtitle "Purchase a plan" and then click "Get Started" on the plan? That needs work - "Get Started" should be "Signup".. especially since you use "Get Started" on the front page to go to the docs. IMO, getting to signup from the index should be easier.
Overall I like this service.. But I think your users are right.. the pricing and account management needs to be simplified. These are just my thoughts after a few minutes--you know more than me here, so feel free to ignore anything you think is offbase.
Edit: are there not actually accounts on this service? The pricing page just shows a stripe payment popup. If so, consider changing that.. this could be simple. Ask for email+password, give a dashboard with a few charts (like query counts), a profile, and subscription info. Now the user can login, change their subscription, upgrade to a paid account, and you have their email to market improvements and upsell to.
Thanks for all the feedback and sorry for the connection hiccup.
This is still a very early version of the service. Account management is currently limited to signing up via Stripe and getting an email with your API key and a how to get started guide :)
I can make the free tier more obvious, you really don't need an account or credit card to get started with the API that's why "Get Started" links to the docs. You can just copy and paste the commands/code examples and get started. I see now that's it's not at all clear and will fix this.
Otherwise I'd say the pricing units are really just the number of calls. A really interesting idea might be to have a comparison on the site between my service and Maxmind's web service!
Some really basic account management like you describe is very much in the works. There're currently no accounts on the site. But it's something I'd like to do possibly offering a higher free tier quota to users who sign up, so that I'm able to communicate with them and have stats on conversion etc
It sounds like you're heading in the right direction.
I think adding the accounts, improving the signup flow, and reducing the number of plans would go a long way. It seems like those are bigger issues than the pricing itself.
After getting a better handle on the service, one issue that occurred to me: how do you track the free tier usage? I assume its by request IP, but that should be stated in the docs. That could be another advantage of signing up for a free account -- to be able to see your usage; and knowing that you're below the max would provide some peace of mind and make them more comfortable building on the API.
I really dislike pricing per API call, because I'm vulnerable to bugs or attacks (on my or your side) that can cause the pricing to blow up.
Also, I have the impression of getting screwed because there is no relationship between my usage and your cost (unless your API call is a call to a really complex task, 1000 calls will cost you mere pennies in equivalent CPU time, so the more I use your service the bigger your relative margin!).
The only place I am happy to pay per use is for cloud services, where I rent CPU and I get billed per time used.
And to handle traffic spikes. I however pad my user's daily quotas (by a percentage of their plan) to be able to handle temporary spikes up to a certain point.
The answers HN readers give won’t be representative of the “revealed preferences”[1] your prospective customers - even if both are from the same person. Get 10 people excited about your product and have conversations/casual pricing negotiations with them.
> 8. Customers are bad at telling you how much they would pay: Before we added the paywall, we asked a sample of users if they’d be willing to pay a fee to remove a watermark. The majority said they wouldn’t be. But when we actually added the paywall, several people who said they wouldn’t pay did. After we launched, some people have told us our product is cheap and plenty have said it’s too expensive. Takeaway: The easiest way to tell if people will pay is to make them an offer and see if they cash in.
I think a good way to price this out is logarithmic pricing. $1 for the first 1000, an additional $1 for the next 2000, then $1 for the next 4000, etc. Play with the numbers, based on how many calls you expect the bulk of the smaller customer to make, yet still cover your expenses if you land a handful of very large customers.
69 comments
[ 3.4 ms ] story [ 77.3 ms ] threadFor a company, having your largest customers have negligible marginal cost for increased usage seems unwise.
If you’re thinking about how to price a product of your own:
1) nothing wrong with starting very simple because you’re not making your product better by writing billing code
2) common answer to your question is “do both” — google two part tariff
1) I can offer discounts on annual prepayments which helps cash flow and gives the user a bargain
2) The payment is upfront and there's no need to send dunning emails at the end of the month when several user's card payments fail.
Generally I prefer flexible pricing, since we might need to scale up - i.e. if we double some limit, I want to be able to pay $60 rather than be blocked.
Some other considerations:
1. Have a free tier to let developers play with your API. i.e. first 1000 calls per month are free.
2. If you do variable pricing, let people set a limit and alert them before they hit that limit.
As most others will probably say: it depends. If your service is a commodity that I can switch out for another service easily, perhaps a fixed monthly fee is the only way to go. But if it’s a very unique service, metered may be the way to go.
The trick is to align your pricing with the API consumer's value received. You want a piece of their take for the value you're delivering.
Only having to pay when we use it helps keep the overhead down dramatically. I've never considered looking at other options because it's been great.
For developers, too, I think the pay-per-usage or fixed-monthly model works well when it's something that they can tangibly understand. Looking at my example above, I'm fine with the fixed monthly DO cost because I know that there's some fraction of some real computer "out in the cloud" that is reserved for me and that is running my code continually. I also know that Twilio has a finite number of phone numbers available, and $1/mo to reserve one of those makes sense to me. But I also know that the way most telecom agreements work is that they bill based on usage, so me getting charged based on usage works fine for me. If they wanted to charge me $20/mo for a number even if I had not sent any messages at all, that'd be harder to swallow.
Edit: also, it probably depends on whether you're selling to small businesses or enterprises. My experiences with enterprises is that they seem to prefer having fixed costs even if it ends up costing more. Seems like it has to do with how budgets and funds get allocated. "Our SMS sending costs went up by a factor of 100 because it's Christmas" doesn't seem like something that flies very well, even if the pay-per-usage model averages out lower over time.
What do u use Twilio for? Is it pure telephony based product?
Otherwise for constant usage I'd prefer to be able to know my spending ahead of time.
So if you're innovating on the product.. market the innovations to your users, and focus their attention on the benefits of your innovations. They should be big, obvious improvements--think 10x (not 10%). For pricing, copy it from your competitors.
If you're innovating on the pricing, then that's frequently a freemium model... but it could also be flat-rate pricing, etc. To build a foothold in an existing market, you'll need to aim for pricing that's 1/10th of your competitors. If you're going to deliver a big price cut like this, you should make it as obvious to your customers as you possibly can.
So the answer to your question very much depends on your strategy, but also the industry you are in and how your competitors price their products.
Perhaps the worst thing you could do is both... since innovations cost money and price cuts cost money... it's a great way to die. Doing less of both just creates a mediocre product without clear marketing; making it more complicated for your users to understand the benefits of your service.
- Your index page is missing. (I can't see your marketing angle.. so I'm not going to comment on the actual pricing... let me know when you fix it)
- you're following a freemium model, but it's not obvious enough. The first plan on the pricing page should say "FREE". Your index page (which I cant see), should say free signup & no credit card required.
- That's a lot of plans. Compare to Maxmind, they have 3 plans depending on what data you want (Country, City, Insights) + a free trial.
- In the faq, it says I need to email you to update my credit card or change my plan. I guarantee you some user will email you their credit card number. This should all be available from their account without emailing you.
What I do is ask the user to sign up for the new plan and refund them on a prorated basis for their usage of the first.
But good point I should make this more clear in the faqs.
I'm looking to either cut some of the plans or move to cost per usage, maxmind offer downloads of their data. If I remember correctly their webservice is charged per request but is way more expensive compared to my fixed plans. Whereas I charge by based on an API usage bucket.
Prorating the first month is ok.. but it should be something obvious for the user. Days left in the month is frequently used, and something you can calculate up front. Which means you won't need to issue a refund later. This (like changing plans and credit card numbers) should be built into the signup/account.
If your plans are cheaper than maxmind, that's not obvious at all. Simply because your plans do not follow the same model as maxmind, and to find out if they are cheaper, I would need to convert them manually to the same units. That could be made more obvious.
I don't think the free plan is obvious enough on the front page. The "Purchase a plan" subtitle under the "See the docs" button could be "Signup for a free account". (Edit: Consider adding a free account so users already have data in your system, and just need to upgrade to a paid account. This will also give you email addresses to market to.)
Am I right that the only way to signup for a plan from the front page is to click on "Pricing" in the header or the small subtitle "Purchase a plan" and then click "Get Started" on the plan? That needs work - "Get Started" should be "Signup".. especially since you use "Get Started" on the front page to go to the docs. IMO, getting to signup from the index should be easier.
Overall I like this service.. But I think your users are right.. the pricing and account management needs to be simplified. These are just my thoughts after a few minutes--you know more than me here, so feel free to ignore anything you think is offbase.
Edit: are there not actually accounts on this service? The pricing page just shows a stripe payment popup. If so, consider changing that.. this could be simple. Ask for email+password, give a dashboard with a few charts (like query counts), a profile, and subscription info. Now the user can login, change their subscription, upgrade to a paid account, and you have their email to market improvements and upsell to.
This is still a very early version of the service. Account management is currently limited to signing up via Stripe and getting an email with your API key and a how to get started guide :)
I can make the free tier more obvious, you really don't need an account or credit card to get started with the API that's why "Get Started" links to the docs. You can just copy and paste the commands/code examples and get started. I see now that's it's not at all clear and will fix this.
Otherwise I'd say the pricing units are really just the number of calls. A really interesting idea might be to have a comparison on the site between my service and Maxmind's web service!
Some really basic account management like you describe is very much in the works. There're currently no accounts on the site. But it's something I'd like to do possibly offering a higher free tier quota to users who sign up, so that I'm able to communicate with them and have stats on conversion etc
I think adding the accounts, improving the signup flow, and reducing the number of plans would go a long way. It seems like those are bigger issues than the pricing itself.
After getting a better handle on the service, one issue that occurred to me: how do you track the free tier usage? I assume its by request IP, but that should be stated in the docs. That could be another advantage of signing up for a free account -- to be able to see your usage; and knowing that you're below the max would provide some peace of mind and make them more comfortable building on the API.
I'll mock up something really simple that does just that in the next couple of weeks.
Thanks!
Also, I have the impression of getting screwed because there is no relationship between my usage and your cost (unless your API call is a call to a really complex task, 1000 calls will cost you mere pennies in equivalent CPU time, so the more I use your service the bigger your relative margin!).
The only place I am happy to pay per use is for cloud services, where I rent CPU and I get billed per time used.
1: https://en.wikipedia.org/wiki/Revealed_preference, http://www.beyondcostplus.com/blog/stated-vs-revealed-prefer...
> 8. Customers are bad at telling you how much they would pay: Before we added the paywall, we asked a sample of users if they’d be willing to pay a fee to remove a watermark. The majority said they wouldn’t be. But when we actually added the paywall, several people who said they wouldn’t pay did. After we launched, some people have told us our product is cheap and plenty have said it’s too expensive. Takeaway: The easiest way to tell if people will pay is to make them an offer and see if they cash in.