Metered vs seat-based billing: charge for people or for work

Seat-based billing charges a fixed price for each person with access. Metered billing charges for units of work, such as API calls or renders, counted during the period and billed after it.

Most comparisons of the two end at "it depends". It does, but on one thing, and you can name it. When a customer gets more value from you next month, did they add a person, or did the same people do more work? Answer that honestly and you have your model. Answer it wrong and the pricing page looks fine for a year, then quietly stops tracking what customers get out of the product.

The question that decides it

Ask it about your best customers, not your average one. They are where the answer shows.

If value arrives with people, charge seats. A teammate who needs to see the board or answer the ticket is the unit of value, and the customer already counts it. Their finance team has a headcount spreadsheet, and your price slots straight into it.

If value arrives with work, meter it. Picture two accounts with two people each. One wires your API into a nightly batch job; the other logs in on Fridays. A seat price charges them the same, and one of them is getting a bargain you are paying for.

Then check the answer against your costs. Cost to serve is the tiebreaker, not the question. If an extra unit of work costs you real money (inference, outbound email) and you priced by seat, your heaviest seat is your least profitable customer, and nothing on the invoice will tell you so.

What each model does to the customer's bill

A seat bill moves when somebody makes a decision. An admin invites a teammate and the count goes up; someone leaves and it goes down. The customer can predict next month's invoice by looking at their members screen, and seats are normally charged at the start of the period, so finance approves the number before it is spent.

A metered bill moves when traffic moves. Nobody decided to make more API calls in March. Their own users did, or a retry loop did, and the total lands after the fact as a sum of events the customer never watched accumulate. That is why a usage invoice needs a running number the customer can see during the month, which the usage-based billing explainer argues at length.

So the trade, plainly: seats are predictable for the customer because they bill for a decision. Meters are accurate for you because they bill for an outcome. Neither model gets both for free.

What counts as a seat

"Per person" hides a definition you have to write down. Does a bot account count? What about a teammate who has been invited but has not clicked the link yet?

We had to pick an answer for the billing module BuildBase ships. A pending invitation bills a seat from the moment the email is sent until it is accepted, declined, revoked or expired, and invitations are valid for fourteen days. That choice has a cost: an invitation nobody answers keeps billing. So the server runs a sweep that marks invitations expired and releases their seats within ten minutes of expiry, instead of leaving them on the invoice until the next member change happens to recompute the count. The members screen counts pending invitations in its seat block and says so. A seat the customer cannot see on screen is a seat they will dispute. The invitations reference has the full lifecycle.

What each model does to your revenue

Seats give you a floor. A customer with eight seats pays for eight seats in a quiet month, and next quarter is a forecast built from headcount and churn. The price of that floor is a ceiling: the account whose one seat runs your product all day pays the same as the one that logs in on Fridays.

For one class of product the ceiling is dropping. An agent or a scheduled job does work without taking a seat. When a customer moves work from people to automation, their headcount stays flat or shrinks while their use of your product grows, and seat revenue falls at the exact moment the value you deliver rises. If your roadmap says "agents" anywhere, that is the pricing question to answer first.

Meters give you expansion without a sales call: the customer who doubles their volume doubles their bill. They also give you the reverse, because a customer's slow month is now your slow month. And they leak at seams seats do not have.

The plan change is the seam we know best. A seat change is a quantity change, and Stripe prorates quantity changes by default. Metered usage is a running total, and a plan change has to carry it across. When we measured our own billing module against live Stripe, a plan change over 10,101 reported units produced an invoice with one line on it: the unused-time credit. The usage had been cleared along with the old plan's metered items, so every plan change was throwing away a period of overage on exactly the accounts most likely to have any. The fix, which the proration guide walks through, converts reported usage into its own invoice line before the plan changes. That also makes it readable on the bill.

Nobody has to write that fix for seats. That is the honest revenue comparison: meters capture more of the value, and they have more places to lose it. What it costs to build one that does not lose it is worked through in the cost of building usage metering yourself.

Where hybrids fit: seats plus an allowance

A hybrid is the answer when both things grow: people need a login to get any value, and the work each account does varies a lot from one to the next. Charge seats for access. Include a usage allowance big enough that a normal month never touches the meter. Meter only what goes past it.

The rule that keeps a hybrid fair is that each line charges for something different. The seat pays for a person having access, the allowance covers what a typical team does, and the meter charges for the tail. If your seat price already assumes a person's usage and you meter that same usage from the first unit, you are charging twice for the same work. The first invoice with both lines on it is where the customer works that out.

In practice it is three prices on one plan. A plan version in BuildBase's billing module carries a base price, a per-seat price for members beyond the seats it includes (with an optional cap on total seats), and an overage price per quota. Each quota either bills overage past its included amount or stops at it, and during a trial every quota stops. The allowance belongs to the plan and is shared by the whole workspace. It does not grow with the seat count, so if bigger teams should get more included usage, that goes into the tiers.

Hybrids go wrong on time. A seat changes on a date and is prorated. Usage accumulates and is billed at the end. An invoice that carries a mid-month seat proration next to an overage line is two clocks on one page, and it has to be readable as two clocks. The allowance has its own clock too: it resets every month, so whatever a customer did not use is gone. If unused volume should carry over, you want a balance rather than an allowance, and quotas are not credits is about exactly that choice.

When each one is the wrong choice

Seats are wrong when usage per account varies widely at the same headcount, or when software does the work rather than people. Either way you price for the average and lose money on the tail. They are also wrong when the per-seat price is high enough that a team shares one login, at which point your unit of value is a password.

Meters are wrong when the customer cannot see or control the unit, and when the buyer needs a fixed figure for a purchase order; the usage-based explainer covers both. They are also wrong when access is the value. A tool where the work is reading and commenting has no honest unit to count, and inventing one ("per comment") charges people for taking part.

Hybrids are wrong early. Two lines on an invoice are two things to explain, and a product with a dozen customers does not have the usage data to set an allowance that a normal month never touches. Start with the one model the question picked. Add the second line once you can see the tail you would be pricing.

Where we land ourselves

BuildBase's own plans are neither. They are flat tiers: team members are an included allowance on each plan rather than a per-seat charge, and storage is the only quota that bills over. The rest stop at the allowance.

Once you have picked, the build is the short part. Charging per seat is mostly about the moment the seats run out, and charging per API call puts the meter and the cap in one call.