Esquema de base de datos para planes y entitlements que soporta subidas, complementos, trials y revocaciones sin reglas codificadas, usando tablas claras y comprobaciones.
En la página de precios, los planes parecen sencillos: Básico, Pro, Enterprise. El desorden empieza cuando intentas convertir esos nombres en reglas reales de acceso dentro de tu app.
Hardcodear comprobaciones de características (como if plan = Pro then allow X) funciona para la primera versión. Luego cambia la estrategia de precios. Una característica pasa de Pro a Básico, aparece un nuevo complemento, o una oferta de ventas incluye un paquete personalizado. De repente tienes la misma regla copiada en APIs, UI, apps móviles y jobs en background. Cambias en un sitio y olvidas otro. Los usuarios lo notan.
Un segundo problema es el tiempo. Las suscripciones no son una etiqueta estática; cambian a mitad de ciclo. Alguien sube de plan hoy, baja el mes que viene, pausa o cancela con tiempo pagado restante. Si tu base de datos solo guarda el “plan actual”, pierdes la línea temporal y no puedes responder preguntas básicas más tarde: ¿a qué tenían acceso el martes pasado? ¿Por qué soporte aprobó un reembolso?
Los complementos lo complican porque atraviesan planes. Un complemento puede desbloquear asientos extra, quitar un límite o habilitar una característica específica. La gente puede comprarlo en cualquier plan, quitarlo después o conservarlo tras una degradación. Si la regla está incrustada en código, acabas con una pila creciente de casos especiales.
Estos son los escenarios que suelen romper diseños ingenuos:
El objetivo es simple: un modelo flexible de control de acceso que evolucione con los cambios de precio, sin reescribir la lógica de negocio cada vez. Quieres un único lugar para preguntar “¿pueden hacer esto?” y un rastro en la base de datos que explique la respuesta.
Al final de este artículo tendrás un patrón de esquema que puedes copiar: planes y complementos se convierten en entradas, y los entitlements se vuelven la única fuente de verdad para el acceso a características. Ese mismo enfoque encaja también en constructores no-code como AppMaster, porque puedes mantener las reglas en datos y consultarlas de forma consistente desde backend, web y apps móviles.
Muchos problemas de suscripción empiezan por un problema de vocabulario. Si todo el mundo usa la misma palabra para cosas distintas, tu esquema se convierte en casos especiales.
Estos son los términos que conviene mantener separados en un esquema de planes y entitlements:
Los feature flags están relacionados pero son diferentes. Un feature flag suele ser un interruptor de producto que controlas (rollouts, experimentos, apagar una característica durante un incidente). Un entitlement es un acceso específico por cliente basado en lo que pagan o en lo que les concediste. Usa flags cuando quieras cambiar comportamiento por grupos sin tocar la facturación. Usa entitlements cuando el acceso debe coincidir con una suscripción, una factura o un contrato.
El alcance es otra fuente de confusión. Mantén claras estas ideas:
El tiempo importa porque el acceso cambia. Módelalo directamente:
Ejemplo: Una empresa está en Pro, añade “Reportes avanzados” a mitad de mes y luego programa una degradación a Básico para el siguiente ciclo. El plan cambia más tarde, el complemento empieza ahora y la capa de entitlements permanece el único lugar para preguntar: “¿Puede este workspace usar reportes avanzados hoy?”
Un buen esquema de bases de datos para planes y entitlements empieza pequeño: separa lo que vendes (planes y complementos) de lo que la gente puede hacer (características). Si mantienes claras esas dos ideas, las subidas y los nuevos complementos serán cambios de datos, no reescrituras.
Aquí hay un conjunto práctico de tablas que funciona para la mayoría de productos por suscripción:
products y usan una columna product_type.plan_features si separas planes): una tabla de unión que indica qué características vienen con cada producto, normalmente con un valor.La potencia está en esa tabla de unión. Las características rara vez son solo on/off. Un plan puede incluir max_projects = 10, mientras un complemento puede añadir +5. Por eso product_features debería soportar al menos:
feature_value (número, texto, JSON, o columnas separadas)value_type (booleano, entero, enum, json)grant_mode (reemplazar vs añadir), de modo que un complemento pueda “añadir 5 asientos” en lugar de sobrescribir un límite baseModela los complementos también como products. La única diferencia es la forma de compra. Un producto de plan base es “uno a la vez”, mientras que un complemento puede permitir cantidad. Pero ambos se mapean a características de la misma forma. Esto evita casos especiales como “si complemento X entonces habilita Y” repartidos por el código.
Las características deben ser datos, no constantes en código. Si hardcodeas comprobaciones de características en varios servicios, terminarás enviando desajustes (la web dice sí, móvil dice no, backend discrepa). Cuando las características viven en la base de datos, la app puede hacer una única pregunta consistente y puedes desplegar cambios editando filas.
El naming importa más de lo que la gente espera. Usa identificadores estables que nunca cambien, aunque cambie el nombre de marketing:
feature_key como max_projects, sso, priority_supportproduct_code como plan_starter_monthly, addon_extra_seatsMantén las etiquetas de presentación separadas (feature_name, product_name). Si usas AppMaster’s Data Designer con PostgreSQL, tratar estas keys como campos únicos paga enseguida: puedes regenerar de forma segura manteniendo integraciones y reportes estables.
La mayoría de los sistemas de suscripción se desvían cuando “lo que compraron” está en un sitio, pero “lo que pueden hacer” se calcula en cinco caminos de código distintos. La solución es una capa de entitlements: una única tabla (o vista) que represente el acceso efectivo para un sujeto en un punto del tiempo.
Si apuntas a un esquema de planes y entitlements que sobreviva a subidas, bajadas, trials y concesiones puntuales, esta capa es la que hace todo predecible.
Piensa en cada fila como una afirmación: “este sujeto tiene acceso a esta característica con este valor, desde este momento hasta ese momento, de esta fuente.” Una forma común se ve así:
Puedes implementar value de varias maneras: una sola columna texto/JSON más value_type, o columnas separadas como value_bool, value_int, value_text. Mantenlo simple y fácil de consultar.
Las características no siempre son on/off. Estos tipos de valor suelen cubrir necesidades reales de facturación y control de acceso:
can_export = true)seats = 10, api_calls = 100000)support_tier = 2)data_retention = "90_days")Los conflictos son normales. Un usuario puede estar en un plan que permite 5 asientos, comprar un complemento por 10 más y también recibir una concesión manual de soporte.
Establece una regla clara y aplícala en todas partes:
Un enfoque simple es almacenar todas las filas candidatas (derivadas de plan, derivadas de complemento, directas) y calcular un “ganador” final por subject_id + feature_id ordenando por precedencia de source y luego por starts_at más reciente.
Aquí un escenario concreto: un cliente degrada su plan hoy, pero ya pagó un complemento que dura hasta fin de mes. Con starts_at/ends_at en los entitlements, la degradación se hace efectiva inmediatamente para características basadas en plan, mientras el complemento sigue activo hasta su ends_at. Tu app puede responder “¿pueden?” con una sola consulta en vez de lógica dispersa.
Tu catálogo de planes (planes, complementos, características) es el “qué”. Las suscripciones son el “quién tiene qué, y cuándo”. Si mantienes estas cosas separadas, las subidas y cancelaciones dejan de dar miedo.
Un patrón práctico es: una suscripción por cuenta, y muchos items de suscripción bajo ella (uno para el plan base, más cero o más complementos). En un esquema de planes y entitlements, esto te da un lugar limpio para registrar cambios en el tiempo sin reescribir reglas de acceso.
Puedes mantenerlo simple con dos tablas fáciles de consultar:
Un detalle común: guarda cada ítem con sus propias fechas. Así puedes conceder un complemento solo por 30 días, o dejar que un plan corra hasta el fin del periodo pagado incluso si el cliente cancela la renovación.
La prorrata, las facturas y los reintentos de pago son problemas de facturación. El acceso a características es un problema de entitlements. No intentes “calcular acceso” desde líneas de factura.
En su lugar, deja que los eventos de facturación actualicen registros de suscripción (por ejemplo, extender current_period_end, crear una nueva fila en subscription_item, o fijar ends_at). Tu app entonces responde a preguntas de acceso desde la línea temporal de suscripción (y más tarde, desde la capa de entitlements), no desde cálculos de facturación.
Las subidas y bajadas suelen entrar en efecto en un momento específico:
pending_plan_id y change_at en subscriptions para un cambio de plan programado único.subscription_changes (subscription_id, effective_at, from_plan_id, to_plan_id, reason) si necesitas historial y múltiples cambios futuros.Esto evita hardcodear reglas como “las bajadas pasan al fin del periodo” en partes aleatorias del código. El calendario es dato.
Los trials son simplemente acceso acotado en el tiempo con una fuente distinta. Dos opciones limpias:
Si lo construyes en AppMaster, estas tablas encajan bien en el Data Designer (PostgreSQL) y las fechas hacen sencillo consultar “qué está activo ahora” sin casos especiales.
Un buen esquema de planes y entitlements empieza con una promesa: la lógica de características vive en datos, no repartida por rutas de código. Tu app debe hacer una pregunta: “¿cuáles son los entitlements efectivos ahora?” y obtener una respuesta clara.
Crea una tabla feature con una clave estable y legible por humanos que nunca renombres (aunque cambie la etiqueta UI). Buenas claves son export_csv, api_calls_per_month o seats.
Agrega un tipo para que el sistema sepa cómo tratar el valor: booleano (on/off) vs numérico (límites/cuotas). Mantenlo simple y consistente.
Ahora necesitas dos fuentes de verdad: qué incluye un plan y qué concede cada complemento.
Una secuencia simple y práctica es:
feature con claves estables y un tipo de valor.plan y plan_entitlement donde cada fila concede un valor de característica (por ejemplo seats = 5, export_csv = true).addon y addon_entitlement que conceden valores extra (por ejemplo seats + 10, api_calls_per_month + 50000, o priority_support = true).Si lo sacas adelante en AppMaster, puedes modelar estas tablas en el Data Designer (PostgreSQL) y mantener las reglas de combinación como una pequeña tabla de “policy” o un enum usado por tu lógica de Business Process.
Tienes dos opciones: calcular en lectura (consultar y fusionar cada vez) o generar un snapshot cacheado cuando algo cambia (cambio de plan, compra de complemento, renovación, cancelación). Para la mayoría de apps, los snapshots son más sencillos de razonar y más rápidos bajo carga.
Un enfoque común es una tabla account_entitlement que guarda el resultado final por característica, más valid_from y valid_to.
No disperses reglas por pantallas, endpoints y jobs. Pon una función en el código que lea los entitlements efectivos y decida.
can(account_id, feature_key, needed_value=1):
ent = get_effective_entitlement(account_id, feature_key, now)
if ent.type == "bool": return ent.value == true
if ent.type == "number": return ent.value >= needed_value
Una vez que todo llama a can(...), las subidas y los complementos se convierten en actualizaciones de datos, no en reescrituras de código.
Un equipo de soporte de 6 personas está en el plan Starter. Starter incluye 3 asientos de agente y 1.000 mensajes SMS por mes. A mitad de mes crecen a 6 agentes y quieren un pack extra de 5.000 SMS. Quieres que esto funcione sin código especial tipo “si plan = Pro entonces…”.
Creas una subscription para la cuenta con un periodo de facturación (por ejemplo, 1 Ene a 31 Ene). Luego agregas un subscription_item para el plan.
En el checkout (o mediante un job nocturno), escribes concesiones de entitlements para ese periodo:
entitlement_grant: agent_seats, value 3, start Jan 1, end Jan 31entitlement_grant: sms_messages, value 1000, start Jan 1, end Jan 31Tu app nunca pregunta “¿qué plan tienen?” Pregunta “¿cuál es su entitlement efectivo ahora?” y obtiene seats = 3, SMS = 1000.
El 15 de Ene suben a Pro (incluye 10 asientos y 2.000 SMS). No editas concesiones antiguas. Añades nuevos registros:
subscription_item (Starter) end a Jan 15subscription_item (Pro) start Jan 15, end Jan 31subscription_item (SMS Pack 5000) start Jan 15, end Jan 31Luego se agregan concesiones para el mismo periodo:
entitlement_grant: agent_seats, value 10, start Jan 15, end Jan 31entitlement_grant: sms_messages, value 2000, start Jan 15, end Jan 31entitlement_grant: sms_messages, value 5000, start Jan 15, end Jan 31¿Qué ocurre inmediatamente el 15 de Ene?
No hace falta mover usage existente. Tu tabla de uso sigue contando mensajes enviados; la comprobación de entitlement simplemente compara el uso de este periodo contra el límite efectivo actual.
El 25 de Ene programan una degradación de vuelta a Starter comenzando el 1 de Feb. No tocas las concesiones de Ene. Creas ítems futuros (o concesiones futuras) para el siguiente periodo:
subscription_item (Starter) start Feb 1, end Feb 28Feb 1Resultado: conservan los asientos Pro y el pack de SMS hasta el 31 de Ene. El 1 de Feb sus asientos efectivos bajan a 3 y los SMS vuelven a los límites de Starter para el nuevo periodo. Esto es fácil de razonar y encaja bien en un flujo no-code en AppMaster: cambiar fechas crea nuevas filas y la consulta de entitlements se mantiene igual.
La mayoría de los bugs de suscripción no son bugs de facturación. Son bugs de acceso causados por lógica repartida por el producto. La forma más rápida de romper un esquema de planes y entitlements es responder “¿pueden usar esto?” en cinco sitios distintos.
Un fallo clásico es hardcodear reglas en la UI, la API y jobs en background por separado. La UI oculta un botón, la API olvida bloquear el endpoint y un job nocturno sigue corriendo porque comprueba otra cosa. Acabas con reportes confusos de “a veces funciona” difíciles de reproducir.
Otra trampa es usar checks por plan_id en lugar de por característica. Parece simple al principio (Plan A puede exportar, Plan B no), pero se desmorona cuando añades un complemento, un cliente grandfathered, un trial gratis o una excepción enterprise. Si alguna vez dices “si plan es Pro entonces permitir…”, estás construyendo un laberinto que tendrás que mantener para siempre.
El acceso también se queda “pegado” cuando solo guardas un booleano como has_export = true y nunca adjuntas fechas. Cancelaciones, reembolsos, contracargos y degradaciones a mitad de ciclo necesitan ventanas temporales. Sin starts_at y ends_at puedes conceder acceso permanente por accidente, o quitarlo demasiado pronto.
Una comprobación simple para evitar esto es:
Los equipos también se meten en problemas al mezclar registros de facturación y reglas de acceso en la misma tabla. La facturación necesita facturas, impuestos, prorrata, IDs del proveedor y estados de reintento. El acceso necesita claves de característica claras y ventanas temporales. Cuando se enmarañan, una migración de facturación puede convertirse en una caída de producto.
Finalmente, muchos sistemas omiten un rastro de auditoría. Cuando un usuario pregunta “¿por qué puedo exportar?”, necesitas una respuesta como: “Habilitado por Complemento X desde 2026-01-01 hasta 2026-02-01” o “Concedido manualmente por soporte, ticket 1842.” Sin eso, soporte e ingeniería adivinan.
Si lo construyes en AppMaster, guarda los campos de auditoría en tu modelo del Data Designer y haz que la comprobación “¿pueden?” sea un único Business Process usado por web, móvil y flujos programados.
Antes de lanzar tu esquema de planes y entitlements, haz una pasada final con preguntas reales, no teoría. La meta es que el acceso sea explicable, testeable y fácil de cambiar.
Elige un usuario y una característica, luego intenta explicar el resultado como lo harías a soporte o finanzas. Si solo puedes responder “están en Pro” (o peor, “el código lo dice”), sufrirás la primera vez que alguien suba a mitad de ciclo o consiga un trato puntual.
Usa esta lista rápida:
feature.export_csv) en lugar de nombres de plan (como “Starter” o “Business”)? Los nombres de plan cambian; las claves de característica no.Una prueba práctica: crea tres usuarios (nuevo, subido a mitad de mes, cancelado) y un complemento (como “asientos extra” o “reportes avanzados”). Luego ejecuta tu consulta de acceso para cada uno. Si los resultados son obvios y explicables, estás listo.
Si usas una herramienta como AppMaster, aplica la misma regla: haz un único lugar (una consulta o un Business Process) responsable de “¿pueden?” para que todas las pantallas web y móviles usen la misma respuesta.
La mejor forma de mantener las subidas sensatas es empezar más pequeño de lo que piensas. Elige un puñado de características que realmente importen (5-10 es suficiente) y construye una comprobación de entitlement que responda a una única pregunta: “¿Puede esta cuenta hacer X ahora mismo?” Si no puedes responder eso en un lugar, las subidas siempre serán riesgosas.
Cuando esa comprobación funcione, trata las rutas de upgrade como comportamiento de producto, no solo como comportamiento de facturación. La forma más rápida de detectar casos raros es escribir un pequeño conjunto de tests de acceso basados en movimientos reales de clientes.
Aquí pasos prácticos que suelen dar resultado inmediato:
Si usas un backend no-code, aún puedes modelar este patrón limpiamente. En AppMaster, el Data Designer es ideal para construir las tablas centrales (plans, features, subscriptions, subscription items, entitlements). Luego el Business Process Editor puede contener el flujo de decisión de acceso (cargar entitlements activos, aplicar ventanas temporales, devolver allow/deny) para que no estés codificando comprobaciones repartidas en endpoints.
La recompensa aparece la siguiente vez que cambias precios. En vez de reescribir reglas, editas datos: una característica se mueve de “Pro” a complemento, cambia la duración de un entitlement, o un plan legacy conserva sus concesiones antiguas. Tu lógica de acceso se mantiene estable y las subidas se convierten en una actualización controlada, no en un sprint de código.
Si quieres validar tu esquema rápidamente, prueba a modelar una subida más un complemento de extremo a extremo y luego ejecuta esos tests de acceso antes de añadir cualquier otra cosa.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
