←back to thread

528 points sealeck | 1 comments | | HN request time: 0.233s | source
Show context
brundolf ◴[] No.31391105[source]
The only thing I don't like is their usage-based pricing. On Heroku I could pay $7 a month and know I'd never be charged more than that. I'm sure when you're scaling a service it's fine - maybe even better - to do it on a sliding scale. But for a fire-and-forget blog site, I don't want to have to worry about stuff like that.
replies(7): >>31391168 #>>31391192 #>>31391253 #>>31391362 #>>31392452 #>>31392496 #>>31395938 #
mrkurt ◴[] No.31391192[source]
This is a problem. And a bit of an own goal on our part.

I hate services that don't put a price on things like bandwidth (because there's always a price!). So we priced bandwidth and made it transparent. You can put an app on Fly.io and server petabytes of data every month, if you want. We'll never complain that you're serving the wrong content type.

But the reality is – having an unlimited bandwidth promise is perfect for for a fire and forget blog site. We're not doing ourselves any favors with scary pricing for that kind of app.

replies(8): >>31391245 #>>31391399 #>>31391400 #>>31391442 #>>31393115 #>>31393823 #>>31394011 #>>31395406 #
EnKopVand ◴[] No.31391400[source]
I don’t want an unlimited bandwidth promise, I want a cap that I know can never be exceeded. I mean, I use Azure professionally and one of the key reasons I don’t use it to host my own stuff is exactly because it could potentially become very expensive. I’d rather have my own stuff shut down until I decide what I want to do with it.

Things like alerts are fine, professionally, but not for things like running a small app, blog or whatever, that you’re not sure where is heading.

I don’t think anything I’ve build on my own time has ever ended up breaking my bank, but signing up my credit card is a risk I’m never going to take, and I’m fairly certain I’m not alone in that. Of course I have no idea if there are enough of us to make small scale fixed prices products profitable at scale.

replies(4): >>31391451 #>>31393636 #>>31393664 #>>31393742 #
manigandham ◴[] No.31393636[source]
This topic has been discussed many times. There's no easy solution to what happens after the cap is exceeded - should the vendor delete everything? - which is why so many of them don't bother.

And for customers, it's far easier to negotiate billing disputes then to try and recover from an account deletion because of spending caps (and there have been plenty of examples of companies shutting down because of such a mistake here).

replies(3): >>31395003 #>>31395377 #>>31399802 #
newaccount74 ◴[] No.31399802[source]
It's pretty simple: Ask people when signing up if they want to set a spending limit or not. If they do, return HTTP 500 as soon as the spending cap is reached. If it's for storage, return a quota exceeded error. Obviously the vendor shouldn't delete data, that would be stupid.

A lot of people try to get hobby users on a platform as a form of PR -- if you don't have spending caps, you are probably going to scare a lot of them away.

And I've never heard a company shutting down because they exceeded a limit -- I've only heard of people being surprised by unintended extremely high bills.

replies(1): >>31415018 #
1. manigandham ◴[] No.31415018[source]
> "Obviously the vendor shouldn't delete data, that would be stupid"

Since data accrues charges over time, there is no alternative if you want a hard cap. Which is why none of this is very simple at all and requires a tremendous amount of planning and complexity just to implement, let alone all the possible new issues and mistakes it creates for customers.

Again, this is the typical "write some code in a weekend" approach that's missing all context of what it actually takes. And as I mentioned before, it's far easier to just negotiate billing then to deal with the aftereffects of whatever service and data disruption this feature would cause for the tiny fraction of customers that end up with this problem.

Waving your $5 fee is far easier and cheaper than spending millions on trying to avoid it in the first place, only to get replaced with potential complains that a production account was suspended or deleted.