Packages, Entitlements & Add-ons: The Plan Is Not a Sticker
How packages, modules, features, limits, grace periods and temporary overrides fit together without hardcoding commercial logic into the app.
A package is not just a label on an organization. It decides which modules are available, which features are enabled, which quotas apply, and what happens when a tenant reaches a limit. If that logic lived in scattered if-statements, every pricing change would require a small ceremony and a deploy.
Package engine
ReVend stores plans, modules, features and limits as data. Runtime helpers read the active tenant package and decide whether routes, actions and quota-bound mutations are allowed. The public pricing page reads from the same catalog, so commercial copy and app behavior are not secretly maintained by two different weather systems.
Four tiers and a sandbox
The catalog ships four plan tiers: free for auction-only bidders, starter for Core operations plus auction browse and bid, professional adding Market, the escrow seller flow, API, webhooks and auction publishing, and enterprise with advanced auction controls and custom terms. A separate sandbox flag on an organization lowers the API rate limit without changing the tier, so an integration can be built against real endpoints without real volume. Tiers are rows, not code branches; a fifth one would be an insert.
Entitlements
Entitlements cover module access, sub-features and numeric limits such as users, storage and API volume. Storage, for example, is 0 GB on free, 5 GB on starter, 25 GB on professional and unlimited on enterprise, unless a platform admin sets a per-tenant quota. Downgrades do not delete tenant data; they block new over-limit actions and explain what changed. The tenant sees all of this on /settings/billing: the package, the modules in and out, live usage against the limits, and — when a gated module sent them there via ?upgrade=... — which module or feature triggered the visit. Explanation, not checkout.
Room without a plan change
Between “over the limit” and “new contract signed” there is usually a conversation, and the platform has two tools for that gap. A grace period keeps a tenant working while a billing or package discussion runs; a temporary limit override lifts a specific limit until a chosen moment, with a note that says why. Both are set from the organization detail in Admin and both are meant to be temporary enough that future support is not confused. “Temporary asset limit override during go-live import cleanup, valid until the fifteenth, package review scheduled” is a good note. “Need more” is not.
Admin control
Platform owners and staff manage the matrix from /admin/platform/plans; platform viewers see it read-only. Packages can be created, edited, duplicated and archived, with a public flag that decides whether the pricing page shows them and a featured flag for the card that gets the highlight. The module matrix switches modules per package; the feature matrix toggles editable features, opens a limit dialog for limit-type features (a value or unlimited) and decides whether a feature shows on the pricing card and in the comparison. Standard features are protected from direct toggling. Changes are audit-sensitive because one switch can move a tenant from “working normally” to “why did Market vanish?” Pricing flexibility is useful only when it leaves footprints.