n8n vs Make vs una solución a medida: cómo elegir

Respuesta corta: usa Make cuando el trabajo consiste en unos pocos saltos sencillos entre aplicaciones SaaS, el volumen es modesto y nadie va a auditarlo nunca. Usa n8n cuando necesitas lógica real, autoalojamiento, código personalizado dentro de los pasos y la posibilidad de mantener los flujos en control de versiones. Encarga una solución a medida cuando el proceso es clave para cómo la empresa genera o protege dinero: cuando toca datos regulados, tiene que sobrevivir a un fallo parcial sin que nadie se dé cuenta, necesita un rastro de auditoría que satisfaga a un responsable de control o a un inspector, o funciona a volúmenes donde la facturación por operación de la plataforma deja de tener sentido.

La versión honesta es que la mayoría de las organizaciones acaban usando dos de las tres. Una plataforma low-code es la herramienta adecuada para la larga cola de integraciones pequeñas que nunca justificarían abrir un ticket de ingeniería. Un sistema de ingeniería es la herramienta adecuada para los tres o cuatro procesos que de verdad importan. El error que nos llaman a arreglar es casi siempre el mismo: un proceso que empezó como un escenario low-code modesto se volvió crítico, y ahora nadie puede explicar qué hace, quién lo modificó por última vez, ni por qué el trimestre pasado se saltó doscientos registros sin avisar.

En qué es realmente bueno Make

La fortaleza de Make es la rapidez para tener algo funcionando. Un analista de negocio que entienda el proceso puede montar una integración funcional en una tarde, ver los datos moviéndose de forma visual y pasársela a un compañero. La biblioteca de conectores es amplia, el lienzo visual hace que la ramificación sencilla sea legible para quien no es ingeniero, y no hay infraestructura que mantener.

Eso lo convierte en una buena opción para:

• Notificaciones y enrutamiento: el envío de un formulario crea un ticket, avisa en un canal, añade una fila.
• Movimiento de datos de bajo volumen entre dos sistemas que tienen APIs decentes.
• Prototipar un proceso que piensas formalizar más adelante, para conocer los casos límite reales antes de invertir tiempo de ingeniería.
• Trabajo departamental donde el propio departamento es responsable del resultado y el radio de impacto de un fallo es la tarde de un equipo.

Dónde se queda corto: la gestión de errores es funcional pero superficial, así que una ejecución fallida a mitad de un escenario de varios pasos tiende a dejar tus sistemas a medio actualizar, y alguien tiene que reconciliarlo a mano. No existe un modelo de desarrollo real con ramas y fusiones, así que si dos personas mejoran el mismo escenario a la vez, el problema de coordinación se resuelve preguntándose el uno al otro. Probar significa ejecutarlo contra algo real. Y el modelo de precios es por operación, lo que significa que el coste crece con lo mismo que intentas aumentar: el volumen. Los equipos descubren con frecuencia que el escenario que era barato como piloto se convierte en una partida de gasto en cuanto gestiona todo el volumen.

En qué es realmente bueno n8n

n8n ocupa una posición intermedia muy útil. Mantiene el lienzo visual, pero puedes bajar a JavaScript o Python dentro de un nodo cuando la lógica supera lo que da de sí la interfaz, y puedes autoalojarlo dentro de tu propia red. Ese último punto importa más de lo que parece: en muchos flujos de finanzas y sanidad, lo decisivo no son las funciones, sino si los datos salen de tu perímetro y qué tercero tiene las credenciales de tus sistemas de registro.

n8n autoalojado también te da los primeros pasos hacia una disciplina de ingeniería real. Los flujos se pueden exportar como JSON y subirlos a un repositorio, lo que significa que puedes compararlos, revisarlos y promocionarlos de una instancia de pruebas a producción en lugar de editar en directo. No es lo mismo que una base de código —el JSON tiene forma de máquina y una revisión de código con sentido es difícil— pero está lejos de andar haciendo clics directamente en producción.

Dónde se queda corto: el autoalojamiento es un compromiso operativo real. Alguien tiene que encargarse de las actualizaciones, de la base de datos que hay detrás, del modo cola y el escalado de workers, de las copias de seguridad, de la rotación de secretos y de la monitorización que te avisa de que un flujo dejó de ejecutarse a las 3 de la madrugada. Los equipos que adoptan n8n para evitar coste de ingeniería a menudo se sorprenden al descubrir que lo que han contratado es trabajo de plataforma. Los flujos complejos también se vuelven realmente difíciles de leer: pasadas unas pocas decenas de nodos con ramas anidadas, el lienzo que hacía claras las cosas sencillas vuelve opacas las complicadas. Y merece la pena leer con detenimiento las condiciones de licencia sobre integración (embedding) y uso comercial antes de construir sobre él un producto de cara al cliente.

Qué te aporta realmente una solución a medida

"A medida" no significa escribirlo todo desde cero. Significa que la automatización es una aplicación versionada: código en un repositorio, pruebas que se ejecutan antes de desplegar, un modelo de datos definido, registros estructurados, reintentos e idempotencia diseñados para los modos de fallo concretos de los sistemas implicados, y controles de acceso conectados a tu proveedor de identidad actual. La mayor parte de lo que construimos para los clientes se apoya mucho en servicios gestionados y librerías ya existentes: lo "a medida" es la lógica del proceso y las garantías que la rodean, no reinventar una cola de mensajes.

Lo que obtienes y que a las plataformas low-code les cuesta ofrecer:

• Corrección ante un fallo parcial. Si el paso cuatro falla después de que los pasos uno a tres ya confirmaron cambios, un sistema de ingeniería sabe cómo dejar eso a salvo: acciones compensatorias, claves de idempotencia, una máquina de estados persistente que retoma en lugar de reiniciar. Esta es, con diferencia, la mayor diferencia, y la que solo sale a la luz después de la puesta en producción.
• Rastros de auditoría que satisfacen a un auditor. No "la plataforma registró una ejecución", sino un registro inmutable de qué decisión se tomó, sobre qué entrada, bajo qué versión de las reglas, con qué identidad, y quién aprobó la excepción. Si tu proceso está dentro del alcance de SOX, HIPAA o de la inspección de un regulador, esta suele ser la razón para dejar el low-code.
• Control de versiones y de cambios. Pull requests, revisión, despliegue por fases y una reversión que tarda un minuto. Cuando las reglas cambian a mitad de trimestre, puedes demostrar qué registros se procesaron bajo cada versión.
• Coste que escala con la computación, no con los pasos. Los procesos de alto volumen se abaratan por transacción a medida que crecen, en lugar de encarecerse.
• Trabajo que exige criterio. Cualquier cosa que implique comprensión de documentos, clasificación o razonamiento sobre entradas no estructuradas necesita bancos de evaluación, umbrales de confianza y enrutamiento con supervisión humana. Eso es ingeniería, no configuración. Es el núcleo de nuestro trabajo de inteligencia documental y de datos.

El coste es honesto y merece decirse: una solución a medida tarda más en dar su primer valor, exige una conversación de requisitos de verdad y crea algo que necesita un responsable. Si nadie va a hacerse cargo de ella, no la construyas.

Los techos, uno al lado del otro

Cuando la respuesta es "todavía no hay que automatizar esto"

Rechazamos trabajo de automatización con regularidad, y estas son las razones. Si el proceso no está documentado y tres personas lo hacen cada una a su manera, automatizarlo solo convierte la versión de una persona en política de la empresa: mapéalo primero. Si los datos de origen no son fiables, la automatización convierte un proceso manual lento en uno rápido y equivocado; en su lugar, arregla los datos o crea validación como primer proyecto. Si el proceso está a punto de cambiar por una migración de sistema, una reorganización o una nueva normativa, espera al cambio y automatiza el destino. Si nadie es responsable único del resultado, lo que construyas se pudrirá en menos de dos trimestres.

Y si el proceso se ejecuta unas pocas veces al mes y tarda unos minutos cada vez, la automatización costará más en atención de lo que cuesta en tiempo el trabajo manual. Nuestra calculadora de valor es una forma rápida de comprobar si el volumen y el tiempo de gestión justifican algo antes de discutir sobre herramientas.

Rutas de migración que no exigen reescribirlo todo

Nadie debería arrancar de raíz un parque low-code que funciona. El patrón que funciona es tratar los escenarios de la plataforma como la fase de descubrimiento y migrar de forma selectiva, en este orden:

• Inventario y clasificación. Enumera cada escenario, quién es su responsable, qué toca, con qué frecuencia se ejecuta y qué se rompe si se detiene. La mayoría de las organizaciones descubren que una parte considerable de los escenarios están muertos, duplicados o superados. Retíralos primero: es capacidad gratis.
• Clasifica por consecuencia, no por complejidad. Los escenarios que hay que migrar son aquellos en los que un fallo silencioso cuesta dinero, rompe un control o falsea una cifra. Un escenario complicado que solo envía notificaciones puede quedarse donde está.
• Extrae la lógica, no el diseño. Antes de migrar, escribe las reglas de negocio reales en lenguaje llano, incluidas las excepciones que la gente gestiona a mano. El escenario es un artefacto de la herramienta; las reglas son el activo.
• Ejecuta ambos en paralelo, comparando resultados. Haz que el nuevo sistema corra en sombra junto al antiguo con datos reales hasta que se expliquen todas las diferencias. Cada diferencia es o un fallo en la nueva solución o un comportamiento no documentado de la antigua; ambas cosas merece la pena conocerlas antes del cambio definitivo.
• Conserva la plataforma para los bordes. Un núcleo a medida con low-code en la periferia para notificaciones, informes puntuales y necesidades departamentales aisladas es un estado final legítimo, no una solución de compromiso. Es como acaban la mayoría de nuestros proyectos de automatización de procesos.

Migrar de Make a n8n suele ser una reconstrucción, no una conversión: los modelos de nodos difieren lo suficiente como para que una traducción automática produzca algo en lo que no puedes confiar. Migrar de n8n a código a medida es más fácil, porque los nodos de código que ya escribiste suelen recoger las partes difíciles de la lógica y se pueden trasladar conservando su intención.

Cómo decidir, en la práctica

Hazte cuatro preguntas sobre el proceso concreto que tienes delante. ¿Qué pasa si falla en silencio durante una semana: una molestia, o una cifra errónea en una declaración? ¿Es probable que un auditor, un regulador o un cliente te pida algún día demostrar qué hizo en una fecha concreta? ¿El volumen hace que el precio por operación empeore con el tiempo? ¿Y hay un responsable con nombre que vaya a mantenerlo? Con dos o más respuestas incómodas, estás ante una solución de ingeniería. Con cero, la plataforma low-code es la opción correcta y más barata: úsala y sigue adelante.

Nuestro enfoque de trabajo empieza mapeando el proceso y deja para el final la discusión sobre la herramienta, porque los requisitos determinan la respuesta, y esa respuesta suele ser menos ambiciosa de lo que esperaba el comprador.

Si estás valorando una plataforma frente a una solución a medida para un proceso concreto —o ya tienes un parque low-code que ha crecido más de lo que puede soportar con seguridad— habla con nosotros. Una conversación de alcance suele bastar para saber cuál de las tres opciones necesitas, y si la necesitas ya.

Preguntas que nos hacen sobre esto