El problema que nadie nombra
Cuando se habla de automatización, la conversación suele quedarse en el backend: los workers, las colas de mensajes, los logs de errores. El frontend se trata como un accidente necesario, la capa cosmética que alguien tiene que construir para que el cliente no tenga que escribir curl desde la terminal. Ese prejuicio es un error de categoría.
La interfaz no es decoración. Es el punto donde un sistema autónomo negocia sus permisos con el ser humano que lo opera. Cada pantalla es, en el fondo, una declaración de intención: esto es lo que el robot puede hacer, esto es lo que tú decides activar.
EMW fue, durante varios años, mi plataforma de automatización de mensajería para clientes empresariales. Este es su frontend. Y construirlo me obligó a pensar con precisión en esa negociación.
Qué hace el sistema
La plataforma permite a una empresa conectar su cuenta de WhatsApp, definir una lista de clientes con etiquetas y campañas, configurar mensajes con archivos adjuntos, y luego encender un robot que los envía de forma secuencial. El frontend expone exactamente esas capas: gestión de clientes, configuración de mensajes, administración de sesiones de WhatsApp, métricas del robot en tiempo real, y un sistema de suscripción con pagos.
El stack es Next.js 13 con TypeScript, Redux Toolkit para el estado global, Bootstrap para los componentes visuales, Chart.js para las métricas, y Firebase para el almacenamiento de archivos. La autenticación viaja en cookies; el robot consulta su propio estado cada diez segundos mediante un intervalo en el componente de métricas.
Eso es lo que dice el código. Lo interesante es por qué el código dice eso.
El robot como ciudadano de segunda clase
El concepto central de la plataforma es la distinción entre dos tipos de agentes: el operador humano y el robot. El humano configura, el robot ejecuta. Pero esa distinción, que parece obvia, genera una cantidad sorprendente de problemas de diseño.
¿Cuándo debe el robot detenerse por su cuenta? ¿Cuándo debe esperar instrucción? ¿Qué información merece mostrar en tiempo real y qué puede diferirse? El dashboard de métricas, que refresca el estado cada diez segundos, es una respuesta pragmática a esas preguntas: el robot reporta con suficiente frecuencia para que el operador pueda intervenir, pero no tan frecuentemente como para saturar la conexión.
La página de sesiones de WhatsApp es aún más reveladora. El sistema puede perder la sesión, el QR puede caducar, la reconexión puede fallar. Cada uno de esos estados tiene que ser comunicado con claridad sin alarmar innecesariamente. El frontend aquí actúa como un traductor entre los estados técnicos de la librería de WhatsApp y el lenguaje que un operador no técnico puede entender y sobre el cual puede actuar.
El modelo de dominio como espejo de la realidad del cliente
Algo que encuentro instructivo, revisando el código años después, es la estructura del tipo Customer. Tiene campos como prefix, phone, firstName, lastName, companyName, y también data1, data2, data3.
Esos tres campos genéricos no son pereza de diseño. Son honestidad epistémica. Cuando construyes un sistema para clientes reales, descubres rápidamente que cada negocio tiene atributos propios que no caben en ningún esquema previo: el número de cédula, el tipo de producto que compra, la zona de despacho, el nombre del asesor que lo atiende. Crear campos específicos para cada cliente es inviable. Los campos genéricos son la solución correcta, y el hecho de que estén en el tipo central del dominio dice algo sobre cómo evolucionó el entendimiento del problema.
Lo mismo aplica al sistema de etiquetas (label[]) en tanto en clientes como en mensajes. Una etiqueta es una relación de pertenencia sin estructura rígida: este cliente pertenece a esta campaña, este mensaje aplica a este segmento. Modelar eso con etiquetas en lugar de relaciones estrictas es elegir flexibilidad sobre precisión, y en el contexto de una PYME con campañas cambiantes, esa es la apuesta correcta.
Suscripciones y la infraestructura del permiso
El sistema tiene un modelo de suscripción con periodicidad mensual o anual, pagos con tarjeta de crédito tokenizada, y roles de usuario (NORMAL, SPECIAL, FREE). El frontend gestiona la pantalla de planes, muestra la fecha de próxima renovación, y diferencia la experiencia según el rol.
Esto introdujo una capa de complejidad que va más allá de lo técnico: la interfaz tiene que ser honesta sobre lo que el usuario puede o no puede hacer según su plan, sin ser condescendiente, sin bloquear de forma opaca. El componente PremiumBanner es un intento de resolver eso: un recordatorio que informa sin interrumpir.
Construir ese tipo de componentes obliga a pensar en el contrato implícito entre el producto y el usuario. No es solo diseño de UI. Es ética de producto, aunque nadie la llame así.
Lo que aprendí sobre sistemas de larga duración
EMW vivió desde 2023 hasta 2026. Tres años es una eternidad en el ciclo de vida de un proyecto personal. Lo que hace que un sistema dure no es la arquitectura perfecta del día uno, sino la capacidad de absorber cambios sin colapsar.
El frontend de EMW no tiene la elegancia de un sistema diseñado desde cero con todo el conocimiento final. Tiene las cicatrices de un sistema que respondió a clientes reales, a sessiones caídas a medianoche, a campañas que cambiaron de criterio a mitad de ejecución. Esas cicatrices son información.
La interfaz, al final, no es un problema de diseño visual. Es un problema de modelado del mundo: cómo representar el estado de un sistema autónomo de una forma que permita a un humano entenderlo, confiar en él, y cuando sea necesario, detenerlo.