The Only Type of API Services I'll Use | Hacker News Reader

The Only Type of API Services I'll Use

rdegges.com

210 pointszdw61 comments

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

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.

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

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.

I work for a huge enterprise software vendor and even internally I’ve heard the rise of the cloud as “don’t have to talk to a sales guy as a service”. I was sitting in the room when one of our clients got fed up with our sales process (we’ll have a quote to you in two weeks) and called a competitor, who had a solution spun up in AWS in under 5 minutes.

Unfortunately enterprise sales are a self perpetuating cycle. Vendors do it because customers want it, and customers do it because that’s how the vendors are set up to work, because customers have been demanding it for so long.

What those customers actually want is long term stability and someone to blame when things go wrong. The drawn out sales cycle is just one manifestation of that, but doesn’t have to be the only one.

> “don’t have to talk to a sales guy as a service”

I haven't heard this before, and it's great. I always get a chuckle when customers are dumbfounded that they don't have to have a call with us before using Geocodio. They're so used to the self-perpetuating sales pattern you mentioned that they're confused it could be so straight forward.

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.

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.

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.

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.

Most bucket-based APIs I’ve used allow you to go beyond your tier and you’re either automatically bumped up to the next expensive tier or charged overage rates (i.e. SendGrid). If you use less than you commit to they keep the extra but go over and it’s automatically usage based.

Either way bucket pricing is designed to work out better for the provider than the customer almost every time.

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.

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

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.

There usually are different Ali suppliers that are either more b2c or b2b focused and offer variable balance between free to cheap single user upwards to enterprise. APIs are priced similiarly.

Also utility is physically providing wherein the distribution of an api is already existant.

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.

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.

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.

It depends on the type of service, setting up new accounts to dodge charges can be very annoying if there's any kind of data to move around, and it would be easy to spot for the service provider.

Like everyone else does, Facebook, Google, Digital Ocean, Amazon. You bill low amounts $25, $50, keep going up as you trust them.

Like utility companies do.

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

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

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

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.

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 ?

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.

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.

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

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?

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.

That makes sense! How do you justify the buying of an API financially? Do you compare total cost of ownership of an outsourced solution with the cost of building and maintaining it?

Does control/risk factor into your decisions? I mean when working with an external provider there's always the risk that the API will go down and disrupt your service. Do you have any criteria to evaluate the trustworthiness of a provider?

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.

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

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

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.

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.

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.

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.

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.

Yes that got me too. AWS hit me with hundreds in bandwidth costs when I made a mistake. Guess there's pros and cons.

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

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

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.

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

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

Isn't that rather easy to block? Who would pay more than the public pricing info says?

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.

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.

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

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

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.

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

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

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.

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.

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.

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.

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.

A linear discount would be more fun.

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.

If you look at Google One, they actually charge more for each increment on a per-GB basis for the first few increments.

Reply on news.ycombinator.com