planes de suscripcion

[hectorlozgo]

`

Es una tarea fundamental para la monetización de FlowKan. El objetivo principal es encontrar las barreras de valor adecuadas, limitando ciertas funciones o cantidades sin inutilizar la aplicación para el usuario gratuito.

A continuación, defino una estructura de tres planes de suscripción (Free, Pro y Business) y detallo exactamente qué funciones se limitarán o habilitarán en cada uno.

Característica | Plan Gratuito (Free) | Plan Pro | Plan Business -- | -- | -- | -- Tableros Totales | 3 | Ilimitados | Ilimitados Columnas por Tablero | 5 | Ilimitadas | Ilimitadas Tareas Totales | 50 | Ilimitadas | Ilimitadas Miembros/Usuarios por Tablero | 3 (total, incluyendo al creador) | 20 | Ilimitados Roles de Usuario (Personalización) | Solo Miembro (rol fijo) | Roles Personalizados Básicos (Ej: "Lector", "Editor") | Roles Personalizados Avanzados con permisos granulares (ACL) Adjuntos y Notas de Voz (Almacenamiento Total) | 200 MB | 5 GB | 1 TB Funciones de IA (Generación de Descripción de Tarea) | 5 usos/mes | 30 usos/mes | Ilimitados Chat en Modo Agente (AI) | No disponible | Disponible (50 mensajes/mes) | Disponible (Ilimitado) Chat con Miembros del Tablero | Ilimitado | Ilimitado | Ilimitado Asignación de Usuarios/Labels | Ilimitado | Ilimitado | Ilimitado Visualización de Drag and Drop | Ilimitado | Ilimitado | Ilimitado Soporte | E-mail Básico (respuesta 48h) | E-mail Prioritario (respuesta 24h) | Chat y Teléfono (respuesta 4h)

Exportar a Hojas de cálculo

---

1. Estrategia de Limitación (Definición de Planes)

El modelo a seguir es el de limitación de cantidad (soft limits) y limitación de funciones avanzadas (hard limits) para incentivar la conversión.

A. Plan Gratuito (Free)

El plan gratuito debe ser funcional para un equipo muy pequeño o para uso personal, pero restrictivo en escala y privado de la automatización avanzada.

• Límites Duros (Hard Limits):

  • IA Agente (Chat AI): Se elimina. Esta es una función premium que impulsa la eficiencia.

  • Roles Personalizados: Se elimina la capacidad de crear roles. Todos los invitados son "Miembros" con capacidad de edición completa.

• Límites Suaves (Soft Limits):

  • Cantidad de Recursos: Se limitan los tableros, tareas y el número de usuarios totales.

  • Almacenamiento: Se impone una cuota baja de almacenamiento total.

B. Plan Pro

Dirigido a pequeños equipos (SME) que necesitan aumentar su capacidad y aprovechar la IA para la productividad.

• Aumento de Capacidad: Introduce tableros y tareas ilimitadas, y un aumento significativo en miembros por tablero y almacenamiento.

• IA de Productividad: Se desbloquea el Chat Agente (con límite para fomentar el salto al plan superior). Se aumenta el límite de uso de IA para descripción de tareas.

• Mejoras de Colaboración: Se habilita una gestión de roles personalizada básica.

C. Plan Business

Dirigido a empresas y grandes equipos con altas necesidades de seguridad, escalabilidad y automatización total.

• Escalabilidad Total: Se eliminan todos los límites de cantidad (miembros, tareas, uso de IA, etc.).

• Funciones Críticas de Negocio: Lo más importante es la seguridad y el control. Se introduce la gestión de roles granulares (ACL) que es vital para cualquier organización.

• Almacenamiento Premium: Cuota de almacenamiento masiva.

2. Repercusión en el Código (Próximas Tareas)

El siguiente paso, una vez definida la estructura, es crear un proyecto de desarrollo y asignar tareas para implementar estas restricciones.

La tarea de integración de la pasarela de pago (como mencionaste) es crucial, pero la aplicación de los límites en el frontend y backend es la tarea directa que sigue a este análisis.

Tareas de Implementación de Límites Clave

ID | Tarea | Componente Afectado | Descripción de la Lógica -- | -- | -- | -- T-101 | Limitar Creación de Tableros | BoardCreationModal, Backend | Antes de crear un nuevo tablero, el backend debe verificar si el usuario tiene un plan Free y si ya posee 3 tableros. T-102 | Limitar Miembros por Tablero | TaskDetailModal (Sección Usuarios), Backend | Antes de invitar o añadir un asignado, el backend debe contar los usuarios únicos en el tablero. Si Plan Free > 3 miembros, denegar invitación. T-103 | Limitar Uso de IA (Agente y Descripción) | useAI Hook, Backend | Implementar un contador de uso mensual para las funciones de IA. Si el plan es Free, deshabilitar el Chat Agente y mostrar un mensaje de upgrade en la descripción al exceder los 5 usos. T-104 | Restringir Acceso a Roles | Settings del Tablero | Ocultar la opción de crear o editar roles personalizados para usuarios Free y Pro (solo permitir la edición de permisos granulares en Business). T-105 | Implementar Cuota de Almacenamiento | Backend de handleUploadAttachments | Antes de cargar un archivo, el backend debe calcular el uso total de almacenamiento del usuario. Si la carga supera la cuota (200MB, 5GB, 1TB), denegar la subida.

Organización del Backend (Fuente de Verdad) 🔒

El backend es el único lugar donde debe residir la lógica de validación.

A. Capa de Datos (Base de Datos)

Se requieren dos modelos o tablas principales:

1. SubscriptionPlan: Define los límites para cada plan.

   • id: PRIMARY KEY

   • name: (Ej: 'Free', 'Pro', 'Business')

   • max_boards: (Ej: 3, NULL, NULL)

   • max_tasks: (Ej: 50, NULL, NULL)

   • max_members_per_board: (Ej: 3, 20, NULL)

   • ai_description_limit: (Ej: 5, 30, NULL)

   • ai_agent_enabled: (Ej: false, true, true)

   • storage_limit_mb: (Ej: 200, 5000, 1000000)

2. UserSubscription: Enlaza al usuario con su plan actual.

   • user_id: FOREIGN KEY

   • plan_id: FOREIGN KEY a SubscriptionPlan

   • ai_description_count: Contador de usos de IA este mes.

   • current_storage_used_mb: Uso actual de almacenamiento.

   • start_date, end_date: Fechas del ciclo de suscripción (importante para contadores mensuales).

B. Capa de Servicios y Lógica (Servidor)

Implementar guardias de permisos (Guards) en las rutas críticas.

Recurso/Endpoint | Acción de Validación | Lógica de Restricción (Guard) -- | -- | -- Crear Tablero (POST /boards) | checkMaxBoards | 1. Obtener el UserSubscription del usuario. 2. Contar tableros activos del usuario. 3. Si count >= plan.max_boards y plan.max_boards no es NULL, devolver error 403 Forbidden. Añadir Miembro (POST /boards/:id/members) | checkMaxMembers | 1. Obtener el plan_id del creador del tablero. 2. Contar miembros actuales del tablero. 3. Si count >= plan.max_members_per_board y no es NULL, devolver error 403 Forbidden. Generar Desc. IA (POST /tasks/:id/ai/desc) | checkAICountAndPlan | 1. Obtener UserSubscription. 2. Si plan.ai_description_limit no es NULL y count >= limit, devolver 429 Too Many Requests. 3. Si es exitoso, incrementar ai_description_count. Subir Adjunto/Nota (POST /tasks/:id/attachments) | checkStorageLimit | 1. Obtener UserSubscription. 2. Verificar que current_storage_used_mb + size_of_new_file <= plan.storage_limit_mb. 3. Si excede, devolver error 413 Payload Too Large.

Organización del Frontend (UX) 🎨

El frontend solo debe recibir información del backend para decidir qué mostrar u ocultar, y reaccionar a los errores de restricción.

A. Hook Global de Suscripción (useSubscription)

Crea un hook o context global para acceder al estado de la suscripción del usuario.

1. Obtención de Datos: Al iniciar sesión, el backend debe enviar la información esencial:

   • user.planName: ('Free', 'Pro', 'Business')

   • user.limits: Objeto con todos los límites del plan actual (ej: { maxBoards: 3, aiDescUsed: 4, aiDescLimit: 5, ... })

   • user.can: Objeto de flags booleanas precalculadas para simplificar la lógica del componente (ej: { canCreateBoard: false, canUseAIAgent: true, ... }).

2. Uso en Componentes: Utiliza este hook para controlar la interfaz:

   TypeScript

   // Ejemplo en el componente de creación de tableros
   const { canCreateBoard, limits } = useSubscription();
   const { t } = useTranslation();
   const renderCreateButton = () => {
   
   if (!canCreateBoard) {
   
   return (
   
   <Button disabled title={t("upgrade.maxBoards", { count: limits.maxBoards })}>
   
   {t("createBoard")}
   
   </Button>
   
   );
   
   }
   
   return <Button onClick={handleOpenModal}>{t("createBoard")}</Button>;
   
   };
   
   

B. Gestión de Errores de Restricción

Cuando el usuario Free intenta ejecutar una acción restringida (ej: crear un 4to tablero), el backend enviará un error 403 o 429.

• Interceptores Globales: Implementa un interceptor en tu cliente HTTP (ej: Axios) para detectar estos códigos de estado.

• Modal de Upgrade: Cuando se detecte un error de plan (ej: 403 con un mensaje específico como "MAX_BOARDS_REACHED"), muestra automáticamente un Modal de Upgrade detallando por qué la acción falló y las ventajas de actualizar el plan.

C. Implementación en Componentes Específicos

Componente Frontend	Lógica de Visibilidad/Estado
TaskDetailModal (Menú lateral de la IA)	Deshabilitar el botón de Generar Descripción IA si limits.aiDescUsed >= limits.aiDescLimit.
TaskDetailModal (Adjuntos)	Mostrar una barra de progreso de almacenamiento si el plan es Free o Pro. Ocultar si es Business.
Botón de Chat AI (Agente)	Ocultar el botón o mostrarlo deshabilitado con un tooltip "Upgrade to Pro" si user.planName es 'Free' y user.canUseAIAgent es false.
Componente de Configuración de Tablero	Ocultar la opción de Añadir Miembro si el tablero ya alcanzó limits.maxMembersPerBoard.