Comparativa
vs. la competencia
Las comparativas de features son fáciles. Lo difícil es ver qué pasa cuando tienes una BD Oracle de 20 años y necesitas modificar una pantalla a las 7 de la mañana antes del turno de almacén.
| Característica | | Retool | Appsmith | Budibase |
|---|---|---|---|---|
| Hot-deploy en producción | Sí Nativo | No | No | No |
| UI generada desde metadatos BD | Sí Automático | Manual | Manual | Manual |
| Procesos de negocio multi-paso | Sí En metadatos | Con código | Con código | Con código |
| Multi-tenant nativo | Sí | No | No | Limitado |
| Oracle / LDAP empresarial | Sí | Sí | Parcial | Parcial |
| On-premise | Sí | Enterprise | Enterprise | Sí |
| Open-source | Próximamente | No | Sí | Sí |
| Migración desde Versata/LAC | Sí Nativo | No | No | No |
| Precio base /mes | 0 € | ~550 $ | ~480 $ | ~50 $ |
Por qué no Retool
Alguien tiene que dibujar cada pantalla. Para una BD con 50 tablas, eso son semanas de trabajo. e-cometa las genera automáticamente desde los metadatos.
Un cambio en producción requiere publicar. En e-cometa, el cambio está en la base de datos de metadatos — no hay nada que publicar. El próximo usuario que abra la pantalla ya ve la versión actualizada.
La lógica de negocio se acaba programando. Confirmar un pedido, generar el XML o encadenar un aviso son queries y JavaScript que alguien mantiene. En e-cometa un proceso es una secuencia de pasos en metadatos, y se corrige en producción como una pantalla.
El precio escala con editores. En contextos enterprise con muchas apps, el coste de Retool se dispara. e-cometa tiene precios planos por despliegue.
Por qué no Appsmith
Appsmith es la alternativa open-source a Retool. El código está en GitHub, se puede desplegar on-premise. Pero comparte el problema fundamental: la UI hay que construirla a mano.
El soporte a Oracle y bases de datos legacy es limitado, LDAP requiere configuración no trivial, y el hot-deploy no existe. Para una empresa con BD Oracle y LDAP corporativo, no es una opción práctica.
Por qué no Budibase
Budibase tiene el mejor precio del mercado y un enfoque open-source sólido. Es una opción legítima para casos simples. Sus limitaciones: pensado para formularios sobre esquemas simples, sin soporte nativo a Oracle, sin migración desde Versata/LAC, y sin hot-deploy real.
«¿Esto no es low-code?»
En una herramienta low-code, el modelo lo define el fabricante y tu negocio se adapta a él. Aquí el modelo crece con tu negocio, es tuyo, y el runtime que lo ejecuta es código abierto que tu equipo ya conoce.
La regla que lo mantiene así: si un requisito aparece dos veces, deja de ser código a medida y se convierte en metadato. El modelo crece con cada proyecto, el código a medida encoge.
Por qué no low-code genérico con una BD legacy
La mayoría de herramientas low-code están diseñadas para construir sobre bases de datos modernas. Si tienes una BD Oracle heredada, tablas con nomenclatura legacy, o lógica en stored procedures, el low-code genérico no entiende tu esquema.
e-cometa fue diseñado desde el principio para trabajar con esquemas reales, complejos, heredados. El caso de la empresa de distribución industrial — migración desde Versata con Oracle de décadas — es la prueba de que funciona donde otros no llegan.
La pregunta correcta no es "¿qué es más barato?"
¿Cuánto cuesta el tiempo de desarrollo que evito? Un desarrollador tarda 3 semanas en construir pantallas básicas (≈ 6.000–9.000 €). e-cometa las genera el primer día. Con e-cometa no hay nada que amortizar: el plan gratuito no caduca.