Paquetes, entitlements y add-ons: el plan no es una pegatina
Cómo encajan paquetes, módulos, funcionalidades, límites, periodos de gracia y anulaciones temporales sin cablear la lógica comercial dentro de la aplicación.
Un paquete no es solo una etiqueta en una organización. Decide qué módulos están disponibles, qué funcionalidades están habilitadas, qué cuotas se aplican y qué pasa cuando un inquilino llega a un límite. Si esa lógica viviera en sentencias if repartidas por ahí, cada cambio de precios exigiría una pequeña ceremonia y un deploy.
Motor de paquetes
ReVend guarda planes, módulos, funcionalidades y límites como datos. Unos helpers en tiempo de ejecución leen el paquete activo del inquilino y deciden si se permiten rutas, acciones y mutaciones sujetas a cuota. La página pública de precios lee del mismo catálogo, así que el mensaje comercial y el comportamiento de la aplicación no los mantienen en secreto dos sistemas meteorológicos distintos.
Cuatro niveles y un sandbox
El catálogo trae cuatro niveles de plan: free para quienes solo pujan en Auction, starter para operaciones de Core más navegación y puja en Auction, professional, que añade Market, el flujo de vendedor de escrow, API, webhooks y publicación en Auction, y enterprise, con controles avanzados de Auction y condiciones a medida. Un indicador de sandbox aparte en una organización baja el límite de peticiones de la API sin cambiar el nivel, para que una integración se pueda construir contra endpoints reales sin volumen real. Los niveles son filas, no ramas de código; un quinto sería un insert.
Entitlements
Los entitlements cubren el acceso a módulos, las subfuncionalidades y los límites numéricos como usuarios, almacenamiento y volumen de API. El almacenamiento, por ejemplo, es de 0 GB en free, 5 GB en starter, 25 GB en professional e ilimitado en enterprise, salvo que un admin de plataforma fije una cuota por inquilino. Bajar de plan no borra los datos del inquilino: bloquea las acciones nuevas que superen el límite y explica qué ha cambiado. El inquilino ve todo esto en /settings/billing: el paquete, los módulos dentro y fuera, el uso en vivo frente a los límites y —cuando un módulo bloqueado lo ha enviado allí vía ?upgrade=...— qué módulo o funcionalidad provocó la visita. Explicación, no carrito.
Aire sin cambiar de plan
Entre “por encima del límite” y “contrato nuevo firmado” suele haber una conversación, y la plataforma tiene dos herramientas para ese hueco. Un periodo de gracia mantiene al inquilino trabajando mientras se resuelve una discusión de facturación o de paquete; una anulación temporal de límite levanta un límite concreto hasta un momento elegido, con una nota que dice por qué. Las dos se configuran desde el detalle de la organización en Admin y las dos están pensadas para ser lo bastante temporales como para que el soporte futuro no se confunda. “Anulación temporal del límite de activos durante la limpieza de la importación de arranque, válida hasta el día quince, revisión de paquete agendada” es una buena nota. “Necesito más” no lo es.
Control desde Admin
Los propietarios y el personal de plataforma gestionan la matriz desde /admin/platform/plans; los visores de plataforma la ven en solo lectura. Los paquetes se pueden crear, editar, duplicar y archivar, con un indicador de público que decide si la página de precios los muestra y un indicador de destacado para la tarjeta que se lleva el foco. La matriz de módulos enciende y apaga módulos por paquete; la matriz de funcionalidades alterna las funcionalidades editables, abre un diálogo de límite para las de tipo límite (un valor o ilimitado) y decide si una funcionalidad aparece en la tarjeta de precios y en la comparativa. Las funcionalidades estándar están protegidas frente al cambio directo. Los cambios son sensibles para la auditoría, porque un solo interruptor puede llevar a un inquilino de “funciona con normalidad” a “¿por qué ha desaparecido Market?”. La flexibilidad de precios solo es útil cuando deja huellas.