Low-code App Builder
- NestJS
- Prisma
- React
- Redux Toolkit
- CodeMirror
Low-code · Editor visual · Fintech B2B en EE.UU.
Un editor drag-and-drop que le devolvió la autonomía a los equipos de negocio: arman y publican pantallas de producción sin esperar una sola línea de un ingeniero. Lo lideré de punta a punta —backend y frontend— de MVP a producción.
¿Qué problema resuelve el Low-code App Builder?
En un producto financiero regulado, las pantallas que ve el usuario cambian todo el tiempo: campos nuevos, reglas nuevas, flujos nuevos, requisitos de compliance que aparecen de un día para el otro. Cada uno de esos cambios pasaba por ingeniería. Los equipos de negocio y operaciones tenían el conocimiento del dominio pero ninguna forma de actuar sobre él, y los ingenieros perdían buena parte del tiempo en configuración repetitiva de UI en lugar de en el producto central. Una herramienta low-code de mercado cubría parte de la necesidad, pero no podía integrarse en profundidad con los servicios y el modelo de datos propios de la plataforma.
Construí un editor visual de arrastrar y soltar —tipo Retool— que reemplazó a esa herramienta de terceros, con dos mitades: el editor, donde el equipo de negocio compone la pantalla, y la plataforma que la sirve en producción.
¿Cómo se construyó el Low-code App Builder?
El editor es un lienzo donde usuarios sin perfil técnico arman páginas a partir de secciones, columnas y componentes; construyen tablas celda por celda con formatos tipados (texto, número, moneda, fecha, select, checkbox); atan tablas a una fuente de datos por path; y configuran reglas de visibilidad por rol.
Del lado del backend, un servicio organizado en diez dominios —páginas, layouts, tablas, tablas orientadas a datos, versiones, deploy, módulos embebidos, configuración, entre otros— con el ciclo de vida de una versión como abstracción central.
Esta fue la decisión estructural más importante: correr en producción para un producto financiero significa que un cambio descuidado en una pantalla no puede romper un flujo en vivo. Modelé todo el sistema con la lógica mental de Git —branch, deploy, publish— en vez de inventar un ciclo de vida propio.
Publicar toca muchos assets, así que lo saqué del camino síncrono del request y lo llevé a una cola de jobs en segundo plano: el editor se mantiene responsive mientras la publicación corre asíncrona y reporta su estado al usuario. Los eventos del ciclo de vida de una versión se emiten en un event bus para que los servicios vecinos se mantengan sincronizados.
¿Qué decisiones técnicas sostienen el Low-code App Builder?
Type-checking de TypeScript, en el browser
Los usuarios escriben expresiones cortas y funciones de una línea para calcular valores. En vez de dejar que esas expresiones fallen recién en producción, embebí un editor de código que corre TypeScript en el navegador.
- Type-checking en vivo en el browser, no en build ni en producción
- Expresiones de una línea, no scripts completos — acotado a lo que la plataforma puede correr seguro
- El error de tipos aparece mientras se escribe, no después de publicar
El estado de guardado, como ciudadano de primera clase
El autosave es invisible hasta que falla. Modelé el estado de guardado como un dato explícito de la UI, con un indicador persistente.
- El usuario sabe en todo momento si su trabajo está a salvo, no lo tiene que asumir
- Evita la duda clásica de "¿esto se guardó de verdad?" en una herramienta de producción
La capa de IA: lo que construí y lo que descarté
El primer intento de feature de IA fue generación de UI conversacional: describís la pantalla que querés y un LLM la genera. Lo construí, lo evalué, y no se sostenía —era lento, y lo que generaba no era lo bastante preciso como para integrarse bien con los servicios y contratos de datos ya existentes en la plataforma.
El modelo planifica, un pipeline determinístico ejecuta
Ese es el principio de diseño que hizo viable al orquestador. El LLM nunca improvisa efectos secundarios: elige qué tiene que pasar, y llamadas a servicios tipadas, con reintentos y reporte de éxito parcial, deciden cómo.
- Un orquestador interpreta la intención del usuario y arma un plan de ejecución
- Siete agentes especializados delegan, cada uno con su propio razonamiento acotado
- Sin framework de agentes: orquestación directa contra el SDK del modelo, menos capas, debugging más simple
En un sistema financiero, esa separación entre planificar y ejecutar es la diferencia entre una feature usable y un riesgo inaceptable.
Cierre
La herramienta reemplazó al producto low-code de terceros que usaban los equipos, y sacó los cambios de UI por completo de la cola de ingeniería: hoy arman y publican por su cuenta. De todo lo que construí acá, lo que más me importa no es el editor —es haber sabido matar la primera versión de la IA cuando no daba la talla, y reconstruirla sobre un principio simple: que el modelo decida el qué, y que el código decida el cómo.