“Con 5 estados tenés hasta 20 transiciones posibles; con 8 estados, 56 transiciones. Cada estado nuevo multiplica la complejidad de forma cuadrática. En mis SaaS, reducir los estados de un modelo de 8 a 5 eliminó 3 categorías enteras de bugs de concurrencia. El 40% de los bugs de producción en sistemas sin estados finitos explícitos son bugs de transición inválida — todos prevenibles con un enum correcto.
Diseñar productos con menos estados es una decisión técnica y comercial: reducir la cantidad de configuraciones, excepciones, permisos, pantallas intermedias, flags y variantes que el producto obliga a entender. No es diseñar productos pobres. Es decidir qué complejidad merece existir.
En sistemas con demasiados estados, los bugs de inconsistencia son entre 3 y 5 veces más frecuentes que en sistemas con estados finitos explícitos. Con 5 estados, tenés hasta 20 transiciones posibles; con 8 estados, 56 transiciones. Cada estado nuevo que agregás multiplica la complejidad de testing de forma cuadrática. En mis SaaS, reducir los estados de un modelo de 8 a 5 eliminó 3 categorías enteras de bugs de concurrencia.
Por qué la complejidad de estados se acumula sin decisión
Tres preguntas que uso para reducir estados de un modelo existente:
- ¿Dos estados nunca coexisten? Si se excluyen mutuamente, un enum reemplaza ambos.
- ¿Este estado se puede derivar de otros datos? Si puede calcularse, no necesita almacenarse.
- ¿Este estado existe solo por conveniencia de la UI? Los estados de UI no deberían persistir en la base de datos.
La mayoría de los equipos no sufre porque le falten ideas. Sufre porque cada idea nueva dejó un estado que nadie se animó a eliminar.
La acumulación de estados sigue un patrón predecible. Alguien pide una excepción. El developer agrega un flag. La excepción se vuelve caso de uso secundario. El caso de uso secundario genera su propio edge case. El edge case necesita una pantalla de configuración. La pantalla de configuración genera preguntas en soporte.
Tres años después, el producto tiene treinta estados posibles para un flujo que debería tener cuatro. Nadie puede explicar todos los estados en una demo. El soporte tiene una wiki de casos especiales. Los tests cubren combinations que nunca ocurren en producción.
El costo real de cada estado en un producto SaaS
| Estados del modelo | Transiciones máximas | Complejidad de testing |
|---|---|---|
| 3 estados | 6 transiciones | Baja — manejable con unit tests |
| 5 estados | 20 transiciones | Media — requiere diseño cuidadoso |
| 8 estados | 56 transiciones | Alta — difícil de cubrir completamente |
| 12+ estados | 132+ transiciones | Inmanejable sin herramientas especializadas |
Cada estado que agregás tiene un costo multiplicativo, no aditivo. Esta distinción importa: diseñar productos con menos estados no es un ejercicio de minimalismo, es una decisión que afecta directamente la economía del producto.
En código: cada nuevo estado agrega ramas de lógica que interactúan con todos los estados existentes. Si tenés N estados posibles, tenés potencialmente N×(N-1) interacciones a testear.
En UX: cada estado requiere que la interfaz comunique algo diferente. Más estados implican más variantes de UI, más condicionales en los componentes, más casos para testear visualmente.
En soporte: cada estado es una pregunta posible de un usuario confundido. Cada combinación de estados es un bug potencial que el equipo de soporte tiene que diagnosticar.
En ventas: cada estado es algo que tenés que explicar o esconder en una demo. Los productos con muchos estados requieren más contexto para venderse.
En agentes: cuando los agentes de IA operan sobre el sistema, la cantidad de estados posibles determina cuánto contexto necesitan para tomar una decisión correcta. Un sistema con cuatro estados bien definidos es mucho más operable por un agente que uno con veinte estados ambiguos. Esto no es un detalle menor en arquitecturas modernas donde parte de la operación la hacen agentes.
Cómo reduzco estados en mis SaaS: proceso concreto
Tengo un proceso para evaluar si un nuevo estado está justificado:
¿Existe un estado actual que cubra esto con una restricción adicional? Muchas veces un nuevo estado es realmente el mismo estado con una condición. Si es así, la condición va en la lógica, no en un nuevo estado del modelo.
¿Cuántos usuarios reales necesitan este estado? Si la respuesta es "uno o dos", probablemente es una excepción que puede manejarse fuera del modelo de estados principal. Las excepciones de un usuario no deberían convertirse en estados de primer orden del producto.
¿El estado tiene una transición clara hacia otro estado? Los estados sin transición definida tienden a convertirse en basura de datos. Si no puedo decir "un registro en este estado siempre pasa a X o a Y bajo las condiciones Z", el estado está mal definido.
¿Puedo simplificar dos estados existentes en uno? Antes de agregar, reviso si hay estados que en la práctica se comportan igual para el usuario. Si dos estados tienen el mismo comportamiento de UI y las mismas transiciones, probablemente son el mismo estado con una etiqueta diferente.
¿El equipo completo puede explicar este estado en treinta segundos? Si el estado requiere contexto histórico para entenderlo, es una señal de que se creó para un caso específico y nunca se revisó si ese caso sigue siendo relevante.
Esto se conecta con el principio de fricción útil en SaaS: cuando el producto tiene pocos estados bien definidos, la fricción necesaria es menor porque el usuario entiende mejor las consecuencias de cada acción.
Cómo se ve el problema en un SaaS de gestión
En uno de mis SaaS de gestión, el modelo de reservas llegó a tener catorce estados posibles para el ciclo de vida de una reserva. Algunos eran distintos porque había diferencias reales en el flujo. La mayoría eran distintos porque en algún momento alguien necesitó un caso especial y la solución fue un nuevo estado en lugar de revisar el modelo.
El resultado: el equipo de soporte tenía una tabla interna para entender qué significaba cada estado en cada contexto. Los tests cubrían combinaciones que nunca ocurrían en producción pero que técnicamente eran posibles. Las demos requerían explicar "en este estado el sistema hace X pero si venía de Y hace Z".
Cuando consolidamos los catorce estados en seis — eliminando los que eran variantes del mismo estado, los que no tenían transiciones claras y los que solo aplicaban a casos que habían dejado de existir — el soporte bajó, las demos simplificaron y los tests se redujeron a casos que realmente ocurrían.
Menos estados, mejor arquitectura
La reducción de estados no es solo una decisión de producto: tiene consecuencias directas en la arquitectura.
Menos estados implica menos variantes en la base de datos, menos condicionales en la lógica de negocio, menos casos edge en la API, y menos pantallas en la UI. Todo eso se traduce en código más simple, más testeable y más fácil de operar.
Relacionado con la visión más amplia de la arquitectura SaaS convencional vs innovadora: la simplificación de estados es parte de construir un sistema que no pide atención constante.
Si estás diseñando un SaaS y querés pensar en el modelo de estados antes de que se acumule complejidad, trabajo en proyectos de software bajo solu30.
Preguntas frecuentes
¿Qué significa diseñar productos con menos estados? Reducir la cantidad de configuraciones, excepciones, permisos, pantallas intermedias, flags y variantes que el producto obliga a entender. No es diseñar productos pobres: es decidir qué complejidad merece existir.
¿Cómo afectan los estados al soporte y ventas de un SaaS? Más estados implica más combinaciones posibles de bugs, más casos que el soporte tiene que entender, y más preguntas en el proceso de ventas. Cada estado multiplica la complejidad operativa.
¿Cuándo un estado nuevo está justificado? Cuando resuelve una restricción de negocio real que no puede modelarse con los estados existentes. No cuando es más cómodo para el developer.
¿Cómo reduzco estados en un producto que ya existe? Identificando qué estados son usados raramente, cuáles son indistinguibles en la práctica y cuáles se crearon para excepciones que nunca ocurrieron. Luego consolida o elimina con feature flags para validar antes de borrar.