Seat Management

Show which members cost money and stop surprise overages.

involved Monetization

What it adds

Seat accounting that defines which member states are billable, enforces the limit at invite time, and stays reconciled with the billing provider.

What your agent is told to do

1
Define one rule for what consumes a seat — which of active, pending, suspended, deactivated, guest, and service accounts count — and apply that single rule everywhere the number is shown or enforced.
2
Show used, total, and remaining seats wherever members are managed, and state the rule in plain words next to it. A number nobody can predict generates support tickets.
3
Enforce the limit at the point of invitation and again at the point of acceptance. Checking only at invite time lets a batch of pending invites overshoot the plan.
4
When the limit is reached, either block with a clear upgrade path or queue the invite until a seat frees. Pick one behaviour and make it explicit — do not let the invite half-succeed.
5
Reconcile app membership against the billing provider's subscription quantity on a schedule, and alert when they drift. Webhooks are missed and API calls fail; drift is guaranteed over time.
6
Do NOT let a seat reduction remove a member who is required for the organization to function, such as its last owner. Refuse the downgrade and say why.
7
Proration arithmetic and its preview are owned by Proration Preview; call into that rather than computing money here.

Edge cases it handles

Removing and re-adding the same person within a billing period must not be charged as two seats.
A suspended member must follow the stated rule consistently — if suspension frees a seat, reactivation must be blocked when the seats are gone, and the user must be told before they suspend.
Two invites accepted at the same instant must not both take the last seat; enforce the limit with a database-level constraint, not an application read-then-write.
A downgrade below current usage must be resolved before it takes effect — the admin chooses who to remove, rather than the system silently locking people out.
Expired or revoked pending invitations must release their seat immediately, not at the next billing cycle.
A failed payment or cancelled subscription needs a defined seat state; falling back to unlimited is a revenue leak and falling back to zero locks out paying customers.
Where the billing provider disagrees with the app, decide which side is authoritative and repair in one direction only.

Definition of done

One documented rule defines which member states consume a seat, and every count in the app agrees with it.
Used, total, and remaining seats are visible wherever members are managed.
The limit is enforced at both invitation and acceptance, at the database level.
Reaching the limit produces a defined block or queue with an upgrade path, never a partial invite.
App membership is reconciled against the billing provider's quantity on a schedule, with alerts on drift.
A downgrade cannot remove the last owner or silently deactivate members.
Removing and re-adding a member within a period does not double-charge.
The feature matches the existing design system.
No existing functionality is broken.

Related features

Usage Limits

Billing Portal

Upgrade Modal

How it works

1

Copy the link

Grab the Markdown instruction URL for this feature.
2

Give it to your AI

Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
3

It inspects, then implements

Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.