Ask HN: Would you prefer paying $1 per 1000 API calls or $30 fixed monthly? - jonathan-kosgei
======
rgbrenner
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.

~~~
jonathan-kosgei
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.

~~~
rgbrenner
A few comments:

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

~~~
jonathan-kosgei
Please follow this link [https://ipdata.co/](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.

~~~
rgbrenner
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

~~~
jonathan-kosgei
Please try now.

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

~~~
jonathan-kosgei
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

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

~~~
jonathan-kosgei
By IP address, referer and api key.

I'll mock up something really simple that does just that in the next couple of
weeks.

Thanks!

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

~~~
35bge57dtjku
It seems like it'd be far easier to track usage and prevent/resolve disputes
with a monthly charge, too.

~~~
jonathan-kosgei
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.

------
troydavis
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](https://en.wikipedia.org/wiki/Revealed_preference),
[http://www.beyondcostplus.com/blog/stated-vs-revealed-
prefer...](http://www.beyondcostplus.com/blog/stated-vs-revealed-preferences-
pricing)

~~~
troydavis
In case a future reader stumbles across this thread.. today I read someone
else's description of exactly this. From
[https://www.kapwing.com/blog/unexpected-challenges-of-
making...](https://www.kapwing.com/blog/unexpected-challenges-of-making-
money/)
([https://news.ycombinator.com/item?id=16542603](https://news.ycombinator.com/item?id=16542603)):

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

------
dpweb
$1 per thousand with a $30 maximum charge.

~~~
RGamma
I agree with this. This gets you the cheapest offer (pay as you use) while
having an upper cost bound giving you peace of mind.

~~~
ISL
An upper cost bound can also be applied with a hard user-configurabe usage
cap.

For a company, having your largest customers have negligible marginal cost for
increased usage seems unwise.

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

~~~
35bge57dtjku
Maybe x/month plus y/call over a certain amount, for the people who use a
disproportionately large amount of resources?

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

~~~
smt88
I hate pricing schemes like that. They force me to spend time trying to
predict usage, which is often impossible or frustrating.

~~~
borramakot
This seems strictly better than the price/1000 calls, since at least you only
have to predict the order of magnitude of usage.

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

~~~
jonathan-kosgei
It's actually called on each page load so I imagine you'd 100% go for the flat
rate :)

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

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

~~~
drwl
I would agree with this — this question seems like it would be better with
more context.

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

~~~
jonathan-kosgei
There's actually a free tier of 1500 requests a day for development.

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

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

~~~
jonathan-kosgei
I'd probably do the same thing. If I'm not using a service a lot I don't want
to pay for it or I only want to pay when I use it.

Otherwise for constant usage I'd prefer to be able to know my spending ahead
of time.

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

~~~
redindian75
swings from pennies to $200/day!

What do u use Twilio for? Is it pure telephony based product?

~~~
tonyarkles
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 :)

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

~~~
jonathan-kosgei
I actually do both those things! I have a free tier of 1500 requests a day and
once you subscribe you get an email when you're at 90% your usage.

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

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

------
grenoire
Whatever is cheaper, of course!

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

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

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

~~~
jonathan-kosgei
$X could be spread out over the lifetime of the consumer to remove the initial
costs of setup.

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

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

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

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

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

------
sjtgraham
Which allows you to build a viable business?

~~~
jonathan-kosgei
A fixed monthly absolutely does, because;

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.

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

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

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

~~~
detaro
How can you possibly say that without knowing what the product is?

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

------
analogic
this some kinda brain teaser or somethin?

~~~
quadrature
Its an exercise in learning how to price a product.

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

~~~
rhacker
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).

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

