
The Only Type of API Services I'll Use - zdw
https://www.rdegges.com/2020/the-only-type-of-api-services-ill-use/
======
cnj
> Customers know this, and are often apprehensive about these types of deal
> negotiations, so they tend to only go through this process if absolutely
> necessary

Unfortunately, for big enterprises, this isn't true. They (as a company, maybe
not the individual developers inside it) want to go through it. They're the
ones who start the RFP process, and as the service provider, you'll either
follow their process... or they'll buy from someone else, no matter how much
better your API may be.

It depends on the scenario, but this isn't as insane as it may sound. It's
less relevant for, say, a SMS API which is interchangeable, but if you provide
an API service that is deeply intertwined with the processes in that
enterprise, the company needs to evaluate the different providers. This
process is time-consuming one way or the other... they might as well let the
different providers do most of the work for them (which makes sense, because
they know their services).

As for the price negotiation itself: I agree.

Also, an enterprise sales process and usage based pricing are not mutually
exclusive! You absolutely can sell usage based pricing, and both parties
hopefully get the benefits listed.

~~~
tonyedgecombe
I've seen this in my own business. They can't turn this process off even for a
trivial purchase. If you let them they will drag you into the enterprise sales
process whether it makes sense for you or not.

This is why there is a dearth of software in the middle of the market. You can
sell something for less than $1000 because customers can expense it. After
that the sales process forces up costs so much that you get "contact us for
prices" and the hard sell.

~~~
edw
Joel Spolsky wrote about this in detail, OMG, fifteen years ago:

> There’s no software priced between $1000 and $75,000. I’ll tell you why. The
> minute you charge more than $1000 you need to get serious corporate
> signoffs. You need a line item in their budget. You need purchasing managers
> and CEO approval and competitive bids and paperwork. So you need to send a
> salesperson out to the customer to do PowerPoint, with his airfare, golf
> course memberships, and $19.95 porn movies at the Ritz Carlton. And with all
> this, the cost of making one successful sale is going to average about
> $50,000. If you’re sending salespeople out to customers and charging less
> than $75,000, you’re losing money.

[https://www.joelonsoftware.com/2004/12/15/camels-and-
rubber-...](https://www.joelonsoftware.com/2004/12/15/camels-and-rubber-
duckies/)

~~~
robocat
That is talking about one-off sales, not SaaS.

Monthly billing changes his numbers drastically - because now software priced
at $1000 is sold as $100 per month instead.

------
anw
One of the takeaways:

> Usage-based pricing with automatic volume discounting incentivizes both
> parties to grow and win together.

Highly agree, especially if you're trying to see how viable a small project
is. And if it grows quickly, I know I'll get even more value from the service
provider and won't worry about leaving money on the table at the end of each
billing cycle.

> Bucket-based pricing creates an adversarial relationship between you and the
> customer because the customer is always going to pay more for your service
> than they want to.

I do see the viewpoint from the service provider as well, as they know they
have N number of users at P price point, and can more accurately estimate
their monthly revenue, plan out growth budgets, or show higher profits on
price increases.

------
philsnow
I love tarsnap's usage-based pricing, but I think it only works because
there's exactly one metric that they're using to charge me (bytes stored per
time).

If you're trying to charge for a service or set of services but your costs
vary depending on your customers' mix of usage (imagine you're hosting files,
and customers pay you both for storing the files and also for ingress/egress),
suddenly you either have a complicated pricing model ($X per byte-month
stored, $Y per egress byte) or you have to simplify the model down to one
metric, but this has its own problems.

Say you simplify down to just charging for storage. A few customers are going
to figure out that you have "free" ingress/egress and they're going to use
your service as a CDN that's cheaper than any other CDN, and now your costs
are misaligned with what you're charging. Or if you decide to just charge for
ingress/egress but not for bytes stored, a few customers are going to figure
out that you're a "free" AWS S3 Glacier service and again your costs are
misaligned with what you're charging.

You can write a ToS that prohibits this and you can track down these users,
but now you're engaging in adversarial behavior.

I agree with the author that it's best to charge based solely on usage with a
pricing model that isn't too complicated, but if your service isn't amenable
to a simple pricing model, the next best thing is enterprise pricing --
_because_ you want to find customers who are going to be price- / billing-
insensitive, who need your service.

~~~
sriku
Tarsnap user here and I second your love of its pricing model. Business folks
don't seem to like it though and prefer the bucket model. I think love for
this model stems from an engineering mindset where we're happiest aligning our
interests with our customers'.

I read about Michelin's case somewhere that I found interesting. Apparently
Michelin doesn't sell tires to trucking companies - they sell miles. So
they're incentivized to make better tires and miles is all their customers
care about and they don't have to worry about whether Michelin is deliberately
making bad tires just to make more money. Same "utility" logic here I think.

------
wvh
Big companies and organisations often have tightly controlled fixed budgets,
and in my experience it's hard to get variable-rate services approved. In
fact, even for a personal-use account, I'd rather have a fixed amount than
risk that someone abuses my account and I end up with an astronomical bill
that precludes food for the rest of the month.

Personally, I like services that cap you to a "degraded" service level once
you go over your limit, say you get 20TB at full speed, but after that you're
either throttled to 10Mbit for the rest of the month or you pay extra to have
the rate limit lifted.

While I agree with some of the mutual benefits of per-use pricing, as a
customer I would like some control to set usage restrictions at the upper
limit of what I am willing to pay, specifically for services where I don't
have much control over the actual usage.

~~~
philsnow
You raise a very good point here -- personal users are more likely to be
price-sensitive but corporate users are more likely to be grief-sensitive (as
in they don't want to deal with problems, they're willing to throw money at
problems to make them go away to a certain extent).

It's up to service providers to market themselves effectively to the 'right'
audience if they want aligned customers.

------
gnfargbl
> _And if you think of API services as utility companies, it only makes sense
> that they should charge based on usage. After all, imagine what would happen
> if you had to sign a two-year contract stipulating how much electricity
> you’re going to use at home, or if you had to choose a bucket plan for
> electricity that forced you to purchase a set amount of kilowatt-hours of
> electricity._

My utility company pretty much does exactly that: they charge a fixed fee for
the privilege of supplying me at all, and then they charge me for my metered
usage. Different suppliers offer a variable balance between a larger fixed fee
and a larger per-unit cost, so I can shop around and find the optimal supplier
for my usage level.

Why aren't more APIs priced in that way?

~~~
roganartu
Many are, somewhat. It’s common for services to have different overage rates
at different tiers (eg: starter might be $10/m for 10GB and $0.1/GB after,
while pro might be $50/m for 100GB and $0.01/GB after).

They also tend to differentiate on other features and support levels too,
which muddies it a little, but the concept is there.

------
chmike
What the OP fails to explain is how we can ensure that the user pays for the
used service. The problem is that we have to bill after the service usage and
the user could run away without paying and create a new account for his next
use of the service.

That’s the reason of upfront payment and the bucket usage payment model. An
alternative would to pay upfront for a credit of usage, but this would require
to monitor the usage and an action when the credit falls below a threshold.

The model to use depends on the type service we offer. If we can afford the
loss due to people running away without paying the service, then it’s ok to
bill after use. But that wouldn’t be a great business model.

To me, the upfront payment of a usage credit seam the best compromise.

~~~
miki123211
I think the credit-based system is the best compromise. It's even better if
the cusomer can explicitly opt into an automatic top-up option, where they're
automatically billed when their balance falls below a certain threshold. This
is even better than the bucket model, as those who want their service running
at all times won't risk running out of what their bucket offers, whereas those
who don't want to control how much they spend can do the top ups manually.

~~~
franky47
Another point in favour of this model: as the business is in control of the
credit, they can implement custom flows of this virtual money bag without
hitting any charges. Famous example being the $20 offered when signing up on
some hosting services, or referral programs.

------
treis
For an API, or really any software, you have a large fixed development cost
plus a small marginal cost per request. So the problem is that you have to
price your usage high enough to cover the fixed cost. Depending on the usage
that can be hundreds to thousands of times the marginal cost.

Think of an address validation service. The cost to develop the service might
amortize out to $0.50 a request while the infrastructure to run the service
will cost a fraction of a penny per request. To make a profit the company
would charge $0.75 an address. As a customer I might be willing to pay a
dollar per address to validate a billing address. For addresses collected as
part of a marketing campaign maybe it's only one cent. So there's a potential
benefit from the service that isn't being realized due to the pricing.

I deal with this all the time at my job. The vendor of the software I
implement has been offering a fixed price per ticket/process* created. This
pushes us to implement a single big process when combining a bunch of smaller
processes into one bigger one is the better way to do it. It also limits the
problems we can solve to those worth more than X dollars per process where X
is the cost the vendor charges per process executed.

*Stuff like credit card disputes or managing the employee onboarding process

------
mjwhansen
> As a service provider, I love using usage-based pricing models as it means I
> can focus all my energy and effort on what I do best: running a service. It
> lets me focus on the quality of my service above everything else. Usage-
> based pricing also allows me to scale my service’s revenues without hiring a
> large fleet of sales reps.

> Usage-based pricing with automatic volume discounting incentivizes both
> parties to grow and win together. Neither party is in an adversarial
> position with the other.

As someone who runs a company with a pay-as-you-go, automatic-discounts
pricing model, these points resonate strongly. We are always aligned with our
customers and our metrics and incentives are very clear: do things that make
it more useful for the customer.

We have had to add enterprise options because of customer demand, though.
Enterprises really don't like unpredictable pricing and so we've had to create
various flat-rate options for them.

We've found the pay-as-you-go freemium to be a great compliment to enterprise
plans, though. People within a company can try out Geocodio for free or very
cheaply (i.e., no PO required, just throw it on their boss's P card), make
sure it's what they need, and then make the case internally. As a result, we
don't have to do any outbound sales. The pricing model does it for us.

------
franky47
> Your service can support a high amount of throughput (otherwise you won’t be
> able to earn as much revenue if you can’t service the amount of usage
> customers demand)

It's interesting to see this point under that angle, although it makes perfect
sense: you only get paid after traffic has increased, therefore the service
should scale first, then generate money to support infrastructure billing.

The bidirectional coupling of used resources vs revenue makes a lot of sense.

Now on the question of predictability of pricing (on the customer side),
usage-based pricing, in some cases, should have caps to avoid over-spending.
I'm not talking about rate limiting and DoS protections, but rather a way to
tell your customers when they are about to hit a defined threshold, so they
can plan their billing accordingly. This can give the customer the feeling of
a bucket plan, but with optimal pricing and adapted resource usage.

~~~
japhyr
Yes, and those caps and alerts should be seen as beneficial to the service
provider as well as to the customer. I wouldn't want my customers to have
surprise high costs. A well-designed cap or alert should help avoid any major
surprises, and should avoid the awkward situation of customers having to ask
providers to forgive large bills that were accrued accidentally.

Bitter customers are not good in the long run, and caps and alerts help avoid
having bitter customers.

~~~
franky47
Agreed, alerting and hard-capping (limiting consumption) should be seen as
different kinds of thresholds, possibly defined independently by different
parties.

I'm looking into implementing this system in one of my projects, do you have
good resources on this matter ?

~~~
japhyr
I do not, but as a consumer I appreciate the option to choose between an alert
and a cap, or some combination of the two. There are some projects where I'd
want the cap to know I might get an interruption but will never get a large
bill. There are others where I need to keep the service up, and an alert would
be much better than an interruption.

------
fs2
The author doesn't seem to have much experience with running a business. The
enterprise pricing makes a lot of sense when you know you need a service for
multiple years. The bucket based pricing works very well for the example he
mentions, sending SMS.

------
gitgud
> _" Bucket-based pricing creates an adversarial relationship between you and
> the customer because the customer is always going to pay more for your
> service than they want to."_

A great point, but there's also a significant group of people who prefer flat
predictable rates, rather than fluctuating bills.

Examples of popular services with fixed rates; Digital Ocean, Spotify,
Netflix...

Although these aren't API services, they could be using usage based business
models.

------
ThePhysicist
That’s really interesting ! Do you have any feedback on how simple an API can
be to be still useful and how you decide whether to start using one rather
than build a service yourself?

~~~
njsubedi
Even a simple API if it needs maintenance over time should be outsourced.
Examples include geolocation API. You could build one now but it needs to be
constantly updated. Other example is an image processing API that gets better
over time. I usually only build a DIY version of existing APIs when I'm
absolutely sure that I don't have to look back at it frequently.

~~~
amelius
Why would you use a geolocation API in the first place? Nowadays there are
better ways to find the location of the user, and they also respect user
privacy more.

~~~
ThePhysicist
What would be a better way to get the location of the user without geolocating
the IP? Do you mean the HTML geolocation facilities
([https://developer.mozilla.org/de/docs/Web/WebAPI/verwenden_v...](https://developer.mozilla.org/de/docs/Web/WebAPI/verwenden_von_geolocation))?

~~~
amelius
Yes! But for example smartphone OSes have their own ways of doing the same.

------
hermitt
One model not mentioned in the article either solely, or in addition to those
pricing models, is the per-user based model as well. Working in a medium-sized
organization, this adds a billing/contracting barrier to growing usage of a
good service.

Example - you want to try out a service, you sign a contract that has some
cost $X, up to 5 users. It goes well, you want to double usage of the feature,
but you now need to pay $2*X + $Y in order to expand to 15 users, which really
only encompasses a few choice teams.

------
robocat
There must be some way to cap the total bill - stop the service if it exceeds
some $ limit. E.g. prepaid credits that run out.

Professional situation: that unexpected $20000 bill (expected $20) because of
a bug that was causing spurious repetitive calls to a service that is billed
monthly. That huge bill because someone has hacked your infra so they can
abuse your account.

Personal situation: that $2000 phone bill due to unexpected roaming costs.

------
GlitchMr
I would argue enterprise pricing makes sense. When dealing with big companies,
often it's easier to sell enterprise pricing product than usage-based product,
and those companies are willing to pay more for enterprise pricing.

And it's not that you have to only use one pricing method. You can use have
usage-based pricing for some customers and enterprise pricing for some
customers.

------
homero
This is why AWS did so well. I had no problem creating accounts, testing,
playing, because it was fair and i paid for what i used. If i had to register
up front for $50/month I wouldn't know what it is and many other developers
wouldn't be familiar with them nor ready to develop with them.

~~~
tonyedgecombe
The one thing that has stopped me using AWS or Azure is that I can't top-up my
account and know that it would use more than the available funds. It might not
make business sense but I will never sign up for something so open ended as
AWS.

~~~
MaxBarraclough
This problem turned up in recent HN discussion. [0]

Turns out it's possible to get billing alarms from AWS, but it's not something
they make terribly easy. I don't know if it's possible to configure a kill-
switch the same way.

My favourite AWS billing horror-story involves Glacier. Its pricing model used
to be the stuff of nightmares, and caught plenty of people by surprise. [1]

[0]
[https://news.ycombinator.com/item?id=22412869](https://news.ycombinator.com/item?id=22412869)

[1]
[https://news.ycombinator.com/item?id=10921365](https://news.ycombinator.com/item?id=10921365)

------
saberdancer
I've thought about this for our product and I've made a different conclusion.
Our service is combination of hardware and software and in the initial phase
we would set things up. We've decided to go with a bucket based pricing
because we wanted to remove the temptation to try and reduce your total cost
by turning off hardware which is used less often.

When you can reduce your bill by sending 1 less SMS, you get an incentive to
do so. If you are sending 2500 SMS, you cannot really scale down to 1000 in a
meaningful way. On the other hand, having opportunity to grow to 5000 SMS a
day without cost increase give the company opportunity to test out various
ideas which may or may not bring revenue.

All pricing strategies have pros and cons and it is up to each to determine
what fits them the best.

------
alkonaut
> In my opinion, enterprise pricing is an absolute racket.

That's one way of looking at it I guess. The other way of looking at it is
that every company that doesn't charge each customer exactly what they _can
pay_ rather than something possibly less, is leaving money on the table.

~~~
derefr
And an even scarier way of looking at it—or at least, one that _should_ be
scarier to you, as the API provider: if you charge a customer less than
they’re willing to pay, then an “enterprise services” middleman will come
along, and _resell_ your product for what it’s actually worth to these
customers, and capture all the profit.

It’s analogous to selling tickets: if you charge less than the market will
bear, scalpers will come along and buy them all up, and then make all the
profit _you_ could have made reselling the tickets for what they’re “actually
worth.”

~~~
dinkleberg
If you're keeping your operation fairly small and you haven't brought on any
sales staff, I think those "enterprise service" middlemen can be really
helpful.

It took no effort on your part to get those additional users. It might be
indirect, but for a purely API service, I don't think it makes a great
difference.

The risk would be if they implement some layer over your API service and then
down the road shift it to another provider. To avoid that, I would actually
try to find and partner with any such resellers to make sure they stick with
you.

------
barrkel
The more organizationally remote the consumers of an API are from the people
who pay for it in the organization, the more control the paymasters will want
over the total budget, and the more reluctant they'll be to let developers /
users consume the API in an unbounded fashion. This distance increases with
organization size. Thus, being inflexible about only permitting usage-oriented
pricing will make sales harder in organizations over a certain size.

------
philsnow
> And in the case of ISPs like Comcast, what happens if I move? Let’s say I
> move to another address where Comcast doesn’t operate–I’m still going to be
> held liable for paying them for the full duration of my contract, even
> though I’ll be unable to use their services.

I'm fairly sure they just let you out of your contract if you move somewhere
you can't receive their service. Is that not the case?

------
k__
Cloud providers already price usage based. Let's see how long it takes to
bubble up to the end-users.

------
blakewatson
Not an API, but these same reasons are why I love hosting my sites with
NearlyFreeSpeech.NET. It’s all about incentives being aligned. Pay-as-you-go
is great for that.

------
notyourday
The real question is... are there people who are willing to sell you all the
API services that you might want to use based on this API pricing model?

I bet the answer is "nope".

------
MrStonedOne
Don't discount bucket pricing from the consumer side. A small gaming community
or other small noncommercial use would prefer a model of downtime over cost
overrun.

Offer both

------
rospaya
It's interesting that the author used SMS as an example, since the pricing is
way more complicated and providing a discount isn't always feasable.

------
jariel
Apologies to the author but I have to object to the entire premise; these are
'business anti-patterns'.

I feel all of his points imply a misunderstanding of basic business and
microeconomics.

1) Businesses like predictability. Consistency is such an important concept
that stocks that pay regular dividends are worth considerably more than those
that pay irregular dividends. People with consistent credit payments are more
creditworthy than those who are irregular.

This isn't just for the seller, it's also for the _buyer_. A financial manager
would always prefer some type of easy, annual fixed fee all other things being
equal.

It's why you pay less for longer-term AWS EC2 contracts.

Predictability usually reduces the operational burden, which reduces costs and
enables a better deal.

Your own understanding of your own long term business objectives is an
_advantage_ that you can 'signal' down the value chain to your supplier by
engaging in long term contracts. They do the same, and invariably competitive
pressure means lower prices.

This notion of 'Enterprise plans being good for nobody' due to 'adversarial'
notions is basically rubbish, makes no sense.

2) Often, price doesn't matter. In many cases, the surpluses yielded from a
specific product is quite a lot, so much that nobody cares that much about the
price. If your company with $2B revenues uses some service, if it costs $1k or
$10k / year, it makes no difference at all. Nobody wants any kind of headache,
it's like 'tranche pricing' for a haircut.

3) Combined with #2, we have the concept of 'Total Cost of Ownership'. The
product 'features' that can matter more than price are usability and support.
A cheap product that causes headaches is not cheap. A cheap product with
extremely expensive support is not cheap. So consider 'total cost of
ownership'.

On the seller side, they incur costs for giving free or cheap services. It may
simply not be worth their while to deal with the tiny bits of incremental
revenue.

4) The tiering models don't necessarily imply 'more or less value' for one or
the other sides, it depends very much on the actual price - they could all be
a ripoff or a great deal.

5) I don't think any particular pricing model is more or less 'adversarial'
than the other.

6) Different pricing models are usually advantageous to the customer and the
seller. Far from being 'adversarial', it's just the opposite: they enable
customers and suppliers to engage on common ground, by building a financial
premise that makes sense for both parties. Only each individual party
understands their own needs, so more variety means more opportunity for common
ground.

------
MadWombat
The author needs to do some basic math on his example pricing. The way it is
stated it encourages me to upload terabytes of random noise.

~~~
ohazi
He obviously meant $0.01/GB for the _first_ TB, pricing $0.001/GB for the
_next_ four TB, etc., without the discontinuities, just like your taxes.

~~~
tenant
Although I found the price decreasing by 90% at each change somewhat
distracting. 2TB of data costs only 10% more to store than 1TB? People with
less than a terabyte are subsidising the big boys.

~~~
TeMPOraL
It's more like storage isn't the driving factor of the costs. At low end,
you'll have some fixed per-user costs; as you go from mid to high end, you may
enjoy some economies of scale yourself, and you may want to pass some of those
savings on to your customers.

