Somewhere in every platform company there is a number that decides how much a customer may take before the system says no. It might be requests per minute, seats per plan, gigabytes per workspace or jobs per hour, and it was almost certainly set by an engineer, late, in response to an outage, with the intention of revisiting it later. Later never came. The number became the product. And the day the company tries to change it, it discovers that what looked like a technical setting was in fact a promise, made to every customer who built on the assumption that the number would hold, and that promises are far more expensive to renegotiate than configuration.
This is why rate limits and their cousins deserve to be treated as product decisions from the moment they are set, rather than discovered to be product decisions at the moment they are changed. The person closest to the outage sets the limit because they are the one holding the pager, and their goal is to stop the bleeding, not to design the business. That is reasonable in the moment. It becomes a problem when the emergency number is never reconsidered by anyone who owns the revenue, the customer relationship or the roadmap, and a decision that should have been made once, deliberately, is instead made permanently, by accident.
Three limits that look the same
The first step is to admit that not every limit is doing the same job, even when they are all expressed as a number in a config file. Some limits exist to control abuse: they stop a script from taking the service down or draining a shared resource, and they should be invisible to any legitimate user. Some exist to recover cost: they mark the point at which a customer’s consumption starts to cost the company more than the customer pays, and they are really a tier boundary wearing engineering clothes. And some exist as pricing levers: they are set deliberately below what the system could bear, so that customers who need more have a reason to pay more. All three can be the same number. They are very different decisions.
The trouble starts when a company does not know which one it built. An abuse control that is tuned as though it were a pricing lever punishes honest heavy users. A pricing lever that is defended as though it were an abuse control tells customers the company cannot be straight with them. A cost-recovery boundary that nobody has priced becomes a subsidy to the largest accounts. Ask, for each limit the product enforces, which of the three it is, and if the answer is not obvious, that is the finding: the limit was set by whoever was awake, and its purpose has never been decided.
Write it down before you touch it
Changing a limit is where the disguised decision comes due, and the companies that handle it well are the ones that treat the change as a product launch rather than a deploy. Before the number moves, three things should exist in writing. Who is affected, in numbers: how many accounts currently exceed the new threshold, how much revenue they represent, and how many of them are integrations that will break rather than dashboards that will show a warning. What they will do next: pay more, re-architect, complain, leave, or all four in sequence. And what the company will say to them, in advance, in language a customer could forward to their own engineering team without embarrassment.
What looked like a technical setting was a promise, made to every customer who built on the assumption that the number would hold. Promises are far more expensive to renegotiate than configuration.
GitLab’s recent change to its API rate limits, announced and explained publicly well ahead of enforcement, is a reasonable model of the shape this takes when it is done deliberately: the reason is stated, the affected behaviour is described, the timeline is known, and the path for customers who need more is clear. Whether or not one agrees with the numbers, nobody who reads it can claim the change arrived from nowhere. That is the standard. A limit changed silently in a release note is a limit that will be discovered by the customer’s alerting at three in the morning, and that customer will draw their own conclusions about what else the platform might change without telling them.
Limits you can defend
A defensible limit has three properties, and a founder can check any existing limit against them in a few minutes. It has a grace period, so that a customer who crosses it is warned before they are cut off, and the warning arrives somewhere a human will see it. It makes usage visible, so that a customer can see how close they are and plan rather than discover. And it offers a path to more, whether that is a higher tier, a request form or a conversation, so that hitting the limit is the beginning of a commercial discussion rather than the end of a technical one. A limit missing any of these is not a product decision. It is a trap, and customers who fall into traps do not renew.
Visibility deserves a word of its own, because it is the cheapest of the three and the most often skipped. A customer who can see a usage meter climbing towards a ceiling will plan around it, upgrade ahead of it, or at least not be surprised by it. A customer who cannot see the meter experiences the ceiling as an outage, and outages are remembered long after the reason for them is forgotten.
The path to more deserves particular care, because it is where the pricing lever and the trust relationship meet. If the only way past a limit is to open a ticket and wait, the limit reads as an obstacle. If the way past it is a visible plan with a visible price, the limit reads as a boundary between tiers, which is what a pricing lever is supposed to be. The same number, presented two ways, produces two entirely different customer reactions, and only one of them ends with the customer paying more.
The cost of silence
The most expensive way to change a limit is quietly. Silent tightening feels safer to the team doing it, because there is no announcement to write and no pushback to absorb, but it converts every affected customer into someone who found out by being broken, and that experience outlasts the specific incident. Platforms are trusted in proportion to how predictable they are, and a platform that adjusts the rules without saying so has taught its customers that the rules are not really rules. The next time that platform asks customers to build something important on it, they will remember.
Announce the change, then, even when it is small, and especially when it is a tightening. State the reason, the date, the affected behaviour and the path forward. Give people time. Accept that some will complain and that the complaints are the price of being a platform people can plan around. The rate limit was always a product decision. Making it one on purpose is cheaper than making it one by surprise.