This is exactly the sort of thing I'm talking about, but for money rather than computing resources or bandwidth. I'd like a feature that where the requirement is effectively "Fall back to a serving sorry-I'm-poor.html instead of the app if the total monthly bill has exceeded $xxx". For a side project I'm more interested in not paying an unexpected bill than getting traffic.

I think for most companies, it's better to set the expectation that the service costs money, bursts will cost more money, and then forgive outlier charges once or twice. It's tremendously difficult to compete against the AWS's of the world, putting work into features specifically to minimize how much people spend seems like a good way to fail a company.

I may not underestand parent, but it sounds like its not equivalent to a button next to the auto-scale but more like an email and pre-requisite knowledge that it exists?

We were concerned about spending time on marginal features that didn't actually matter much to people, so we "launched" it without building it to see if anyone cared.

So you could perhaps also consider that if it is only marketed when you sign up and not a clearly defined feature some people (like me) will just never sign up at all.

Not even considering something like AWS with a bazillion types of services, say you have a cloud hosting service that runs nothing but auto-scaling clusters of servers billed by the hour. So I set a cap on costs but not cap on scaling up and turn it loose. It gets a hug of death from something, scales to the sky, does serve all of that traffic fine, but burns through my monthly cost cap in an hour. Oops, now it's down entirely for the next 3 weeks or whatever. Does anybody in the world who's willing to pay for hosting something actually want that? I have to doubt it.

On the other hand, capping the scaling size by number of hosts sounds pretty reasonable. Set a cap at say 2x your normal peak traffic. You get a hug from something, it hits the cap. Most of your extra traffic gets errors or really slow responses, but your service stays up, even when the traffic dies down. Your monthly costs are a bit higher than usual, but manageable. That sounds like a much better result to me.

That doesn't even get into stuff like, oh hey we dropped your DB server because you hit your cost cap early and it costs money to keep it running and to create a new backup too, hope you don't miss that data too much!

My guess is that people who are interested in controlling costs are also not getting enough value from auto scaling services. So we're already not attracting those folks, and offering a cost control feature isn't enough to get us over the hump.

If for some convoluted reason this is wrong, then you guys really need to reconsider how you're presenting your prices and to lay out exactly what those convoluted reasons are, because Fly's pricing page certainly tells people that trying to match DigitalOcean's $5 plan is going to cost 10x on Fly.

In those cases, the users will either not know or not think about such expense limits.

The solution is to set relatively strict limits by default and even occasionally warn users about unused/underutilized resources.

But as you said: such features are bad for the bottom line .

And I can appreciate the enormous difficulty of competing with the big 3.

For people who are inexperienced or don't give it much thought, just waiving their overage fees creates a really nice experience. We've had multiple instances of people asking why their bill is so high and being relieved/excited when we explained it and made it go away. People love when we're responsive to problems.

What a customer-hostile thing to say, never working with you!

What if I told you that if you're actually trying to build a relationship with your customers and have them want to do business with you, it's best to focus on solving their problems as opposed to taking as much of their money as possible.

The point is that I'd rather just wave surprise fees than build a bunch of infrastructure to prevent them. From what we can tell, customers almost never have surprise bursts of traffic, but it's something they think about a lot. It's pretty easy to just say "you're not responsible for expenses associated with abuse or attacks or other nasty surprises".

The purpose of a metered service is to give people access to tools and features that would be prohibitively expensive otherwise. The trade off is that the expense also grows incrementally.

I don't want to need to depend on you being in a good mood to waive fees (or more likely, to hope you're not so low on runway that support gets incentives not to waive them until after your next round closes). I don't want to have to guess whether your terms mean what they say, or whether that giant potential bill might magically go away if I incur it and can convince you it was, quote, nasty.

I do want to deal with people who have thought hard about how to build their product in a way that I can depend on and reason confidently about, and who treat me like the seasoned adult I am.

It's also something that people actively dislike about AWS, and thus a good selling point. Albeit it's probably mostly smaller projects that care about this.

You deposit funds (let's say $20) into your account, and as your site consumes resources, it draws from your balance. So $20 is $20. If you set up a crummy low-traffic blog and that $20 lasts four months, then fine. If it lasts two weeks and then there's a surge in traffic, or the server hits some bug that causes it to spiral out of control, then your site gets killed when your balance hits $0. You can set up alerts, but there's a hard limit for how much you can be charged—it's whatever funds you deposited into your account. (Really, that's not even the right way to put it, because you're charged at the moment you deposit them.)

This isn't acceptable for everybody—many businesses would prefer to stay up and be billed after-the-fact. But that use cases is already well-served by the industry. (Overserved, really.) The market segment where the alternative situation is the best fit (pretty much every hobbiest who isn't bringing in a single cent off their side project) is extremely underserved. NFSN is the only provider I know of that even offers this.

So it autoscales up until it hits the maximum threshold and stops. Yes, if the app needed more resources than this, due to a spike in traffic, than performance would obviously suffer. But depending on the budget and needs of the project this might be the preferred outcome over incurring unexpectedly high server costs that you are not prepared to handle.