Packages, entitlements & add-ons: het plan is geen sticker

Een package is niet zomaar een label op een organisatie. Het bepaalt welke modules beschikbaar zijn, welke features aanstaan, welke quota gelden, en wat er gebeurt wanneer een tenant tegen een limiet loopt. Zat die logica verspreid in if-statements, dan vroeg elke prijswijziging een kleine plechtigheid en een deploy.

De package-engine

ReVend bewaart plans, modules, features en limieten als data. Runtime helpers lezen het actieve tenantpackage en beslissen of routes, acties en quota-gebonden mutaties toegelaten zijn. De publieke prijspagina leest uit diezelfde catalogus, zodat commerciële copy en appgedrag niet stiekem door twee verschillende weersystemen onderhouden worden.

Vier tiers en een sandbox

De catalogus levert vier plan tiers: free voor bieders die alleen veilen, starter voor Core-operaties plus veilingen bekijken en bieden, professional met daarbovenop Market, de escrow-sellerflow, API, webhooks en publiceren in Auction, en enterprise met geavanceerde veilingcontroles en maatwerkvoorwaarden. Een aparte sandbox-vlag op een organisatie verlaagt de API-rate-limit zonder de tier te wijzigen, zodat een integratie tegen echte endpoints gebouwd kan worden zonder echt volume. Tiers zijn rijen, geen code branches; een vijfde zou een insert zijn.

Entitlements

Entitlements dekken moduletoegang, sub-features en numerieke limieten zoals gebruikers, opslag en API-volume. Opslag bijvoorbeeld is 0 GB op free, 5 GB op starter, 25 GB op professional en onbeperkt op enterprise, tenzij een platformadmin een quotum per tenant instelt. Downgrades verwijderen geen tenantdata; ze blokkeren nieuwe acties boven de limiet en leggen uit wat er veranderd is. De tenant ziet dit allemaal op /settings/billing: het package, welke modules in en uit zitten, het live gebruik tegenover de limieten, en — wanneer een afgeschermde module hem via ?upgrade=... naar daar stuurde — welke module of feature het bezoek uitlokte. Uitleg, geen kassa.

Ruimte zonder planwijziging

Tussen “over de limiet” en “nieuw contract getekend” zit meestal een gesprek, en het platform heeft twee gereedschappen voor dat gat. Een graceperiode houdt een tenant aan het werk terwijl een billing- of packagegesprek loopt; een tijdelijke limietoverride tilt één specifieke limiet op tot een gekozen moment, met een notitie die zegt waarom. Allebei worden ze ingesteld vanaf het organisatiedetail in Admin, en allebei zijn ze bedoeld om tijdelijk genoeg te zijn dat toekomstige support niet in de war raakt. “Tijdelijke assetlimiet-override tijdens het opschonen van de go-live-import, geldig tot de vijftiende, packagereview gepland” is een goede notitie. “Meer nodig” niet.

Admincontrole

Platform owners en staff beheren de matrix vanaf /admin/platform/plans; platform viewers zien hem read-only. Packages kunnen aangemaakt, bewerkt, gedupliceerd en gearchiveerd worden, met een public-vlag die bepaalt of de prijspagina ze toont en een featured-vlag voor de kaart die uitgelicht wordt. De modulematrix zet modules per package aan of uit; de featurematrix schakelt bewerkbare features, opent een limietdialoog voor features van het type limiet (een waarde of onbeperkt) en bepaalt of een feature op de prijskaart en in de vergelijking verschijnt. Standaardfeatures zijn beschermd tegen rechtstreeks togglen. Wijzigingen zijn audit-gevoelig, want één schakelaar kan een tenant verplaatsen van “werkt normaal” naar “waarom is Market weg?”. Prijsflexibiliteit is alleen nuttig wanneer ze voetsporen achterlaat.