Multi-tenant Sa...
Multi-tenant SaaS usage limits: how to stop one customer from eating your cloud bill
You license your platform to a partner. The contract says "reasonable use". The partner reads it as "unlimited". Three weeks later your AI provider sends an invoice larger than the partner's annual fee.
Nobody acted in bad faith. The contract simply tried to do a job that only software can do.
This article is about that job: how to build usage limits per tenant into a multi-tenant SaaS platform, where they live in the architecture, and how to make them a revenue mechanism rather than a source of awkward phone calls.
Janu Lingeswaran
Updated
How-to
Technical
Why contract clauses fail
A clause that says "maximum 5,000 processed documents per month" is fine as a legal backstop. As a control mechanism it has three problems.
First, you have to notice the breach. That means someone is watching a dashboard, or you find out from the vendor invoice.
Second, you have to document it and raise it with a paying customer who believes they are using what they bought.
Third, by the time you do both, the cost has already landed. The clause lets you argue about it afterwards. It does not prevent it.
Inside your own company this never came up, because your own teams have a natural sense of what normal usage looks like. A partner has no such instinct, and no reason to have one.
Three kinds of limits to build per tenant
Different resources need different enforcement. Most platforms need all three.
Hard caps
For resources where exceeding the limit should simply not be possible: number of seats, concurrent jobs, storage quota, number of active projects or workspaces.
Behaviour: the action is blocked when the cap is reached, with a message explaining why and how to raise it. No overage, no surprise. The tenant admin sees the cap in their settings.
Soft caps with overage
For metered resources where you want growth rather than a wall: documents processed, AI requests, messages sent, API calls, exports generated.
Behaviour: a notification to the tenant admin at around 80% of the allowance, a second at 100%, and beyond that usage continues at a published overage rate. This is where most of your upside lives.
Rate limits
For protecting the platform from bursts regardless of plan: requests per minute, messages per hour, concurrent uploads.
Behaviour: the request is throttled or queued. Rate limits are not a pricing tool. They exist so that one tenant's spike cannot degrade everyone else.
Where the limits live in the architecture
The pattern is the same across stacks.
An entitlements record per organisation. A table (or equivalent) that says what this tenant's plan includes: seats, concurrent jobs, monthly volume, storage, overage rate. It is the single source of truth for "what is this tenant allowed to do".
Metering at the point of consumption. Every billable event (a document processed, a message sent, a job started, a file stored) writes a usage record tagged with the tenant. This is what you aggregate for both enforcement and invoicing. If you cannot attribute a cost to a tenant, you cannot limit it.
One check, called everywhere. A single function that answers "can tenant X do action Y right now?" by comparing current usage against entitlements. Upload, process, send, invite: they all call the same check. When you change a rule, you change it once.
A scheduled aggregation. Roll up usage per tenant per billing period, compare against the allowance, trigger notifications and overage line items.
Sketched out:
That is the entire mechanism. It is a few days of work when designed in from the start, because the tenant ID is already on every record. It is weeks of work to retrofit onto a system that was built for a single customer, because you have to find every place a cost is incurred and add attribution after the fact.
If you are still building, put the tenant ID on everything now, even if you have one tenant.
Turning a limit into revenue instead of a fight
A usage limit that only says "no" is a support ticket waiting to happen. The same limit, presented well, is an upgrade path.
Upgrade prompt at the threshold. When a tenant hits 100% of their allowance, the product offers the next tier or confirms overage pricing, inside the interface, at the moment they need it.
Auto-billed overage at a published rate. No negotiation, no surprise. The rate was on the contract and in the settings page from day one.
A monthly usage email to the tenant admin. What they used, what was included, what the overage was. Partners who can see their usage rarely dispute it.
Usage visible to you. A simple internal view of every tenant's consumption against their allowance, so you see the heavy one coming before the vendor invoice does.
Done this way, your heaviest partner becomes your best customer rather than your biggest cost.
What to put in the contract anyway
Keep it short. The software does the work; the contract just makes it official.
Reference the in-product limits and the tenant's plan
State the overage rate and when it applies
Reserve the right to throttle or suspend for usage that threatens platform stability
Define what a "document", "request" or "message" means, so there is no argument about units
A clause that points at a mechanism is enforceable. A clause that asks for restraint is not.
Checklist before onboarding your first licensed partner
[ ] Primary cost driver identified (the metric that scales fastest with a new tenant)
[ ] Tenant ID on every billable event
[ ] Entitlements record per organisation
[ ] At least one hard cap (seats or concurrent jobs)
[ ] At least one soft cap with 80% and 100% notifications
[ ] Overage rate published in the contract and the settings page
[ ] Usage visible to the tenant admin
[ ] Usage visible to you, per tenant, against allowance
If you can tick all eight, you can hand a partner the keys without worrying about what they will do with them.
For how to set the allowance and the overage rate, see our guide on how to license your software to other companies. For choosing between seat-based and usage-based dimensions, see per seat vs usage-based pricing.
FeatherFlow is a product development agency that designs, builds and ships AI-first and SaaS products for companies that want to move fast without growing their team.
