Un cliente de logística nos contó el trimestre pasado que había gastado 18 meses y aproximadamente 1,4 millones de euros en un proyecto de Mendix antes de abandonarlo. La plataforma manejó las primeras 20 pantallas perfectamente. La pantalla 21 necesitaba una grilla de datos no estándar, y el workaround tomó más tiempo que reconstruir todo el módulo en Angular.
Esa historia es la razón por la que somos cuidadosos con cómo llamamos a DEX Elements. No es low-code.
La trampa del low-code
Las plataformas low-code hicieron una promesa convincente. Construya aplicaciones empresariales sin escribir mucho código. Arrastre, suelte, despliegue. Desarrolladores ciudadanos. La promesa cumple, hasta cierto punto.
Ese punto es el momento en que necesita una regla de validación compleja, un layout no estándar, una grilla de datos con rendimiento crítico o una integración con una API empresarial que no encaja en el modelo mental de la plataforma. Entonces aparece el muro, y el muro es brutal. Está escribiendo lógica dentro de un lenguaje de expresiones propietario, depurando sin herramientas adecuadas y desplegando dentro de un runtime que no puede inspeccionar.
Hemos visto empresas adoptar Mendix u OutSystems para un proyecto y luego dedicar más horas de ingeniería a rodear la plataforma de las que habrían gastado construyendo la aplicación correctamente.
Lo que construimos en su lugar
DEX Elements utiliza descriptores JSON para definir lo que hacen las aplicaciones. Eso suena similar a low-code, pero la mecánica diverge en cuatro formas que importan.
Low-code oculta la complejidad. DEX la hace inspeccionable. El descriptor es una especificación transparente. Léalo, versionelo, compare diferencias, haga code review con las mismas herramientas que el equipo ya usa para TypeScript.
Low-code lo encierra. DEX genera TypeScript estándar. Si un cliente deja de usarnos mañana, sigue siendo propietario de una aplicación normal que cualquier desarrollador puede mantener. No hay dependencia de runtime con nuestra infraestructura.
Low-code limita la extensión. DEX tiene escape hatches explícitas. Cualquier pantalla puede incorporar componentes personalizados escritos en TypeScript puro. El framework maneja aproximadamente el 90% de los casos. El código personalizado maneja el resto, sin penalización.
Low-code cobra por usuario. DEX cobra por la plataforma. Los precios no tienen nada que ver con cuántas personas usan lo que se construyó sobre ella.
La verdadera diferencia
Low-code es un runtime. Se construye sobre él, se despliega sobre él, se escala sobre él. La aplicación no existe fuera de él.
DEX es un generador. Produce aplicaciones que se ejecutan de forma independiente. El framework proporciona estructura durante el desarrollo. La salida es autónoma después del despliegue.
Esa distinción importa enormemente para empresas que no pueden aceptar dependencia de plataforma para sistemas de misión crítica. Aprendieron la lección una vez con Oracle Forms. No cometerán el mismo error con un proveedor de low-code.
Para quién es esto
DEX no es la herramienta adecuada para alguien que construye un formulario de contacto o un flujo de aprobación básico. Hay muchas herramientas para eso.
DEX es para el equipo que construye un módulo ERP de 50 pantallas con reglas de validación complejas, acceso basado en roles, registro de auditoría e integración API en tiempo real, que quiere entregarlo en meses y se niega a aceptar el vendor lock-in como el precio de la velocidad.
Ese es un cliente específico. Sabemos exactamente quiénes son. Están cansados de que les digan que sus únicas opciones son lento y seguro o rápido y encerrado. Creemos que hay una tercera opción, y empieza por hacer que la salida sea suya.