[naniwaduni]

No, this is motivated reasoning brainrot. It's overcomplicating the problem by hyperfocusing on a specific implementation that's already been judged infeasible to justify not doing it.

The actual problem that people want solved is "the customer wants predictable, budgetable upper bound periodic cost". You are not unique in offering a service where this is a desirable property. Realigning this sort of cost structure is the bread and butter of insurance industry, and no, as much as they'd like to, they don't actually do it by making sure to stop the earthquake before it knocks down more of your house than your price cap.

[donavanm]

I dont understand what youre on about. The post I replied to, and many others, use “caps” to refer to limits of service based on billing. This is an endless source of comments on every “cloud” topic. I provided a very brief overview of why large billing systems are more complicated than expected and have an impedance mismatch to the stated desire. But sure, tautological brain rot. Got it. Im sure you have a wealth of experience with metering, billing, and pricing for billion dollar revenue streams.

Now if you have some _other_ proposal for how billing and service limits could function Im legitimately interested. But I dont see anything at all specific or actionable in your replies. Insurance is interesting for _some_ facets. Im curious how you think that aligns with dynamic resource utilization and what happens at the boundary.

[Dylan16807]

> if you have some _other_ proposal for how billing and service limits could function Im legitimately interested.

Billing doesn't have to be so complicated you can't calculate it in less than a minute. That's a technical failure. Surely you can imagine a better way? If you really think it can't be better, then it's hard to argue against "brain rot".

Also on most systems it will work perfectly fine to use an estimate of the price per unit when calculating the bill for the last couple hours.

[donavanm]

Again, unless you have domain expertise I suspect you are drastically underestimating the complexity of reality. As I alluded to earlier metering, pricing, and billing are _at least_ three separate complicated problems in substantial systems. There are multiple metering dimensions that interact with each other, time, and periodicity at a minimum. Saying “do billing better” without either a thorough understanding of the existing system, or an actual concrete proposal, is not useful.

[Dylan16807]

Being separate systems is fine as long as they can all calculate a number within the time it takes to make a cup of coffee. That's not hard if you actually make it a design goal.

I'm sorry that "prioritize it" isn't very helpful, but it's true. If the calculation takes longer than that, it's a management-induced problem.

If we're positing a system that can already do that, then you need to be more specific about the problem you're describing because it's not obvious.

[tptacek]

No, this is a much harder problem than you think it is; it's, like, CAP-theorem problematic. I think you should do the exercise of working through how these billing systems work.

[naniwaduni]

I reiterate that you are not unique in offering a service where the customer's desire for consistent billing and your willingness to provide it are at odds.

[Jgrubb]

Define “consistent billing” please, I don’t even know what that means and I work in this space.

[tptacek]

I don't believe you saw me say that.

[naniwaduni]

The technical problem is not "we are operationally incapable of, say, getting someone else to underwrite insurance contracts". That's not a technical constraint, It's a business decision.

I get that the underlying issue is that your target consumer is whales who eat orders-of-magnitude pricing spreads as normal opex, and that anyone who comes in with a budget is barely a consideration. It's still absurd to pretend that pricing is too hard. Like, I'm not going to confidently assert "lol you can give up C, it'll be a rounding error anyway" but like, billing cycles are absurdly long on the scale of your technical constraints.

[tptacek]

I don't think you've thought very carefully about this, because there are real technical problems here. If we did a cap feature, enabling it would involve disabling parts of our platform. We're just going to go back and forth on this, because I'm not going to write you an essay on this, and you're going to keep saying "it's a business decision" and I'm going to keep knowing you're wrong about that.

For the nth time on this thread: we don't make our quarterly nut billing people looking to spend $50/mo an occasional extra $1000. The people who actually pay the bills here do not want this feature.

They definitely want Accident Forgiveness, though. Which means it's going to cost us money to do this. And that's fine; they're growing, we're growing.

[naniwaduni]

> If we did a cap feature, enabling it would involve disabling parts of our platform.

What I'm saying is that capping billing is not the same thing as shutting down parts of the platform. You're redirecting complaints about the latter by focusing on the difficulty of doing the latter in real time, which is granted but gross overkill.

The former is something that is not only doable, but something that already happens regularly in an informal capacity and nobody believes you don't have the data to price it.

[genewitch]

> If you're really only looking to spend $50, we should put our cards on table and say that we're generally not making product pricing decisions with you in mind.

i think is what gave that vibe off. I was on a read-only phone in bed and saw the quoted message. got up and logged into the PC to think about what to say. It may be time for cloud providers to dissuade small users away, instead.

[donavanm]

Hes telling you the reality. Cloud providers dont want to _dissuade_ hobbyist users. But thats not their target market and they will make business decisions based on the revenue generating customer profile. Thats just being frank and honest.

Major cloud-style companies dont drive significant revenue from your $50/mo cohort. And a $5/mo dev account is basically courtesy for the sales pipeline. The vast vast majority of revenue is “enterprise” sales with private pricing and spend in the hundreds of thousands to millions range.