Ask HN: Would you prefer paying $1 per 1000 API calls or $30 fixed monthly?

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.

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.

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.

1: https://en.wikipedia.org/wiki/Revealed_preference, http://www.beyondcostplus.com/blog/stated-vs-revealed-prefer...

$1 per thousand with a $30 maximum charge.

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 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.

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.

It depends how many API calls I plan to do monthly. So it depends on the service :-)

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.

I'd rather have the choice to pick and the choice to switch later: some thousands of calls can be okay during initial development/testing and the first days of the product, then as I use the API more extensively, I switch to a subscription.

This is similar to how most online content is sold: most require you to subscribe. I follow some NYTimes newsletters, and I'd pay for the individual articles I read, but I don't want to subscribe, even if that may end up being cheaper sometimes.

Fixed monthly, but you'll likely have rate limits of some kind anyway so it's the same thing.

$x/month is much, much more ergonomic for cost planning, requisitions, etc.

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.

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.

Depends on the API.

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.

I'm surprised how many posters interpret this as $1 / call, when the question says it's $0.001 per call.

Possibly you’re just gathering data.

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

Whatever is cheaper, of course!

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.

Do both i.e. charge them $1 for 1000 calls, and cap it at $30 per month for a period of 3 months - after which they would need to sign up for the monthly plan to continue to get the $30 rate.

$X/mo + $y/kCalls. X is for license to the code, y is for API hosting costs. i don't know why we don't see such a cost structure much, it seems the fairest for consumer.

All inclusive/fixed rates are predictable...tend to be budget friendlier. I guess someone doing some rough bootstrapping would want to pay-as-they-go

Depends:

I hate it when companies insist that I pay monthly for something I use infrequently.

For something I need all the time I might be OK with a monthly fee if the price is right.

Seems like people are missing the point of the question. Saying $1 is too expensive for 1000 calls without knowing what that API call does shows you're thinking in terms of value, not in terms of a pricing model that is favorable. The OP hasn't told us if he's doing ML calculations, spinning up machines, painting a Tesla, selling an airplane ticket or what. Think in terms of the pricing model only. Yes it would be nice to know what the service does, but the OP probably can't give that away.

Assuming that $30 represents 30,000 calls I would prefer to pay $1 per every 1,000 and have the flexibility of more granular pricing.

$1 per 1000 easily, because your cost is upfront, a quota means your wasting people’s time by trying to game the cost of each call.

Which allows you to build a viable business?

Depends what the API does. But ultimately depends if I will reach 1000 or go over or under

$1 per 1000 calls, with 10,000 free per month (free tier)

uh, try $1 per 10,000 API calls and maybe you're on to something.

this some kinda brain teaser or somethin?

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.