Cuando un SaaS incorpora varios planes, es tentador resolver cada diferencia con una condición en el código: si el cliente tiene el plan avanzado, mostrar esta opción; si no, ocultarla. El enfoque funciona al principio, pero se vuelve frágil cuando aparecen cambios de suscripción, complementos, pruebas temporales y excepciones comerciales. La pregunta deja de ser qué botón mostrar y pasa a ser qué capacidades tiene una cuenta, quién puede utilizarlas y bajo qué condiciones.
Un modelo claro separa las decisiones comerciales de las reglas que aplica el producto. Así es más sencillo cambiar la oferta, probar una transición y mantener un comportamiento coherente en la interfaz, la API y las tareas internas. Esta guía propone criterios para diseñar ese modelo y detectar cuándo el actual necesita simplificarse.
El plan no debería ser una regla directa de la aplicación
Un plan es una forma de presentar y vender una oferta. Puede agrupar capacidades y límites, pero no debería convertirse en la única fuente de verdad para decidir cada operación. Si la aplicación pregunta repetidamente si una cuenta pertenece al plan «Pro», la lógica queda ligada a nombres comerciales que pueden cambiar aunque la capacidad siga existiendo.
Conviene traducir la suscripción a un conjunto explícito de derechos efectivos. Por ejemplo, una cuenta puede tener habilitada la exportación, un máximo de proyectos y acceso a una integración. El producto evalúa esos derechos, no la etiqueta de marketing. De este modo, cambiar el nombre o la composición de un plan no obliga a revisar todas las partes de la aplicación que mencionan ese plan.
Este desacoplamiento también facilita ofertas no estándar. Dos cuentas con planes distintos pueden compartir una capacidad; una cuenta con el mismo plan que otra puede tener un complemento contratado. La solución no es añadir más ramas condicionales, sino representar de forma explícita el resultado que necesita el producto.
Separar funcionalidades, límites y permisos
Antes de elegir una arquitectura, distingue cuatro conceptos que suelen mezclarse:
- Plan: oferta comercial asignada a una cuenta, con condiciones y vigencia.
- Funcionalidad habilitada: capacidad disponible para la cuenta, como exportar datos o usar una integración.
- Límite de uso: cantidad máxima o cuota aplicable a un recurso, como usuarios, proyectos o almacenamiento.
- Permiso: acción que una persona concreta puede realizar dentro de la cuenta, según su rol o configuración.
Una funcionalidad puede estar incluida en la suscripción y, aun así, no estar permitida para todos los usuarios. A la inversa, un usuario puede tener permiso para gestionar proyectos, pero la cuenta puede haber alcanzado su límite. Por eso, autorizar una operación puede exigir comprobar tanto el derecho de la cuenta como el permiso individual y el estado del recurso.
Define también qué significa cada límite. «Hasta 10 proyectos» puede referirse a proyectos activos, creados durante un periodo o existentes en total. Aclara cuándo se reinicia el contador, qué ocurre al alcanzar el máximo y cómo se tratan los datos que ya superan el límite tras un cambio de plan. Si estas reglas quedan implícitas, el equipo terminará tomando decisiones distintas en pantallas y procesos.
Dónde representar las reglas
La ubicación adecuada depende de la complejidad y de quién necesita cambiar la oferta. Para un producto con pocos planes y cambios poco frecuentes, una configuración versionada junto con la aplicación puede ser suficiente. Es una opción sencilla de revisar y probar, siempre que las reglas no se repitan en muchos lugares.
Cuando negocio necesita ajustar la composición de los planes sin desplegar código, puede tener sentido guardar catálogo y asignaciones en una fuente de datos administrable. Esto introduce responsabilidades nuevas: controlar quién edita la configuración, validar cambios y conservar un historial para explicar qué reglas estaban vigentes en una fecha determinada. La edición dinámica no es una ventaja si cualquier cambio puede dejar cuentas en estados incoherentes.
Una tercera opción es que el sistema de suscripción registre productos, periodos y complementos, mientras el producto mantiene una representación interna de los derechos efectivos. No conviene que cada pantalla consulte directamente el sistema de facturación: además de acoplar componentes, puede producir resultados distintos ante demoras o fallos de sincronización. Establece cuál es la fuente de verdad para cada dato y cómo se actualiza la otra.
En cualquiera de estas alternativas, evita que el mismo significado se implemente de manera independiente en la interfaz, la API y los procesos en segundo plano. Centraliza la evaluación de acceso en una capa reutilizable y documenta su contrato. La interfaz puede anticipar al usuario que una opción no está disponible, pero la API debe volver a validar la operación; ocultar un control no constituye una autorización.
Modelar cambios, transiciones y complementos
Una suscripción cambia con el tiempo. Puede haber una fecha efectiva futura, un periodo de prueba, una renovación pendiente o una baja programada. Guarda el estado y las fechas relevantes, y define qué derechos se aplican antes y después del momento de transición. Evita basar la decisión únicamente en una etiqueta actual si la cuenta ya tiene un cambio acordado para más adelante.
Para cada cambio de plan, responde de forma explícita:
- ¿Cuándo se aplica el cambio: inmediatamente, al final del periodo o en una fecha acordada?
- ¿Qué ocurre con recursos que exceden el nuevo límite?
- ¿Se bloquea la creación de elementos, se restringen otras acciones o se requiere una intervención?
- ¿Cómo se comunica el estado al administrador de la cuenta?
No elimines ni modifiques datos automáticamente como reacción genérica a una reducción de plan. Decide qué acciones quedan restringidas y cómo se recupera una operación normal. Para una funcionalidad contratada aparte, representa el complemento como un derecho independiente, con su propia vigencia cuando corresponda; así no hace falta crear un plan nuevo por cada combinación.
Excepciones por cliente: explícitas, acotadas y revisables
Las excepciones pueden ser legítimas: un piloto, una compensación o una necesidad contractual. El riesgo aparece cuando se implementan como condiciones especiales repartidas por el código o como cambios manuales sin responsable ni fecha de revisión.
Registra cada excepción con el cliente o cuenta afectada, la capacidad o límite modificado, el motivo, quién la aprobó y su vigencia. Si es temporal, define desde el inicio cómo caduca y qué comportamiento sigue a la caducidad. Una excepción sin fecha puede convertirse en parte permanente del producto sin que nadie recuerde por qué existe.
Antes de añadir otra excepción, comprueba si revela una necesidad de producto más general. Si varias cuentas necesitan el mismo complemento, puede ser mejor ofrecerlo como opción. Si una regla depende de una obligación contractual, mantenla identificable y separada de la lógica general. El criterio es que el equipo pueda explicar y revisar el estado de una cuenta sin buscar condiciones dispersas.
Pruebas, diagnóstico y migración
Prueba no solo la asignación inicial, sino también los cambios de estado y sus efectos. Como mínimo, cubre una capacidad habilitada y otra no disponible, un límite justo antes y después de alcanzarse, un cambio de plan pendiente, un complemento que vence y una excepción caducada. Comprueba la misma decisión en la interfaz, la API y los procesos internos que crean o modifican recursos.
Registra información suficiente para diagnosticar por qué se permitió o rechazó una operación: cuenta, derecho evaluado, límite relevante y resultado. Evita incluir datos sensibles innecesarios. Un mensaje comprensible para el usuario puede ser distinto del detalle técnico, pero ambos deberían corresponder a la misma decisión efectiva.
Hay señales de que el modelo necesita revisión: numerosas comprobaciones por nombre de plan, discrepancias entre pantallas y API, excepciones sin propietario, límites cuyo significado nadie puede precisar o cambios comerciales que exigen editar muchas áreas del producto. Para migrar, inventaría primero las reglas existentes; después, define los derechos y límites con nombres estables, centraliza la evaluación y compara sus resultados con el comportamiento actual en casos representativos. Migra por etapas y conserva un mecanismo para detectar diferencias antes de retirar la lógica antigua.
La decisión práctica es modelar lo que el producto permite, no lo que el equipo de ventas llama a cada oferta. Planes y facturación pueden cambiar; las capacidades efectivas, los límites y los permisos deben seguir siendo comprensibles, comprobables y coherentes en todos los puntos de acceso.