Packages, Entitlements & Add-ons: The Plan Is Not a Sticker
How packages, modules, features, limits and future add-ons 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.
Entitlements
Entitlements cover module access, sub-features and numeric limits such as users, storage and API volume. Downgrades should not delete tenant data; they should block new over-limit actions and explain what changed.
Add-ons
Add-ons are the future expansion model: extra storage, API volume, users, onboarding, support or a specific module without forcing a full plan upgrade. Today the package and limit engine is live; self-service add-on billing depends on the Mollie subscription work and the enterprise-override model. In other words: the shelf is built, the price tags are not all printed yet.
Admin control
Platform admins manage packages from /admin/platform/plans. Changes are audit-sensitive because one toggle can move a tenant from "working normally" to "why did Market vanish?" Pricing flexibility is useful only when it leaves footprints.