Per seat vs usa...
Per seat vs usage-based pricing: which one fits a licensed platform?
Short answer: Per-seat pricing charges a fixed amount for every user who has access. Usage-based pricing charges for what is actually consumed: requests, documents, messages, storage. Per seat works when value and cost both scale with headcount. Usage-based works when a single user can trigger large infrastructure costs. Most platforms that are licensed to other companies end up with a hybrid of the two.
That is the textbook version. The rest of this article is about what happens when you apply it to a platform you built for yourself and are now licensing to partners.
Janu Lingeswaran
Updated
Guide
Best Practices
The comparison at a glance
Criteria | Per seat | Usage-based |
|---|---|---|
What you charge for | Number of users with access | Units consumed (requests, documents, GB, messages) |
Predictability for the buyer | High | Low unless capped |
Predictability for you | High revenue, unpredictable margin | Predictable margin, fluctuating revenue |
Risk of losing money on a heavy user | High | Very low |
Billing complexity | Minimal | Needs metering and rating |
Sales friction | Low, easy to explain | Higher, needs a calculator |
Best fit | Collaboration and workflow tools | Infrastructure-heavy products |
When per-seat pricing works
Per seat is the default for a reason. It is easy to explain, easy to invoice, and the buyer can calculate their bill in their head. It fits products where every additional user adds roughly the same value and roughly the same cost: chat tools, CRMs, project management, document editors.
The unspoken assumption is that one user cannot cost you dramatically more than another. For a note-taking app, that holds. A power user and a casual user are a few megabytes apart.
When per-seat pricing fails
The assumption breaks the moment one user can trigger heavy infrastructure. Think of platforms that:
call AI models to extract, classify or generate
run batch jobs, exports or renders
send bulk email or SMS
process or store large data volumes
stream or transcode media
In these products a single seat can cost you more than the entire contract. Here is a worked example from the kind of platform we build.
An AI document-processing platform pays its model provider per page analysed. A partner buys ten seats at a flat rate. Nine of those users review a handful of files a day. The tenth connects the platform to an inbound scanner and pushes 4,000 pages through it every working day. That is roughly 85,000 pages a month, on one seat. At typical model rates, that seat alone costs more than the partner pays for all ten.
The partner is not doing anything wrong. They are using what they bought. The pricing model simply did not match the cost model, and you found out from the invoice.
When usage-based pricing works
Usage-based pricing fixes that problem by construction: every unit the customer consumes is a unit you bill. Your margin is stable regardless of how heavy the customer is. It is how cloud infrastructure, communications APIs and most AI products charge, and it is the natural model for any platform where your own costs are metered.
It also lowers the barrier to entry. A partner can start small and grow into the platform without renegotiating.
When usage-based pricing fails
Two ways, both commercial rather than technical.
Buyers dislike unpredictable bills. A partner's finance team wants a number they can budget. "It depends on how much you use it" is an honest answer and a hard sell. Without a calculator or an example bill, many deals stall here.
Pure usage hides the relationship. If there is no base fee, a partner who goes quiet for a month pays nothing, and you are carrying their onboarding, support and tenant infrastructure for free.
The hybrid most licensed platforms use
Nearly every platform we have seen go from "internal tool" to "licensed to partners" lands on the same structure:
A platform fee per organisation. Covers the relationship: tenant setup, support, a baseline of infrastructure.
An included allowance of the metric that drives your costs. Generous enough that a typical partner never touches the ceiling.
A published overage rate above the allowance, high enough that a heavy partner is profitable rather than painful.
Seats as a secondary dimension at most. A few admin seats included, additional user seats at a flat monthly rate.
This gives the buyer a predictable number for normal use, gives you protection for abnormal use, and keeps the pricing page readable. Two dimensions are fine. Three usually require a calculator.
We cover how to set the actual numbers in our guide on how to license your software to other companies, and how to enforce the allowance inside the product in multi-tenant SaaS usage limits.
Decision checklist
Five questions. If you answer yes to the first one, per seat alone is off the table.
Can a single user cost you more than the contract is worth?
Do your customers need a fixed monthly number for budgeting?
Can you meter usage per tenant today, or would you have to build it?
Is there more than one cost driver in your stack, or does one dominate?
Will every deal be negotiated individually, or do you want a published price?
Most licensed platforms answer yes, yes, "we'd have to build it", "one dominates", and "individually for now". That combination points directly at the hybrid above.
One more consideration: what the partner is used to
If your partners already pay for cloud tools with a base subscription plus limits, they are used to that shape. Matching that mental model makes your pricing feel normal rather than novel. Novel pricing costs you deals even when the numbers are better.
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.
