Cuando un dueño de empresa empieza a buscar cómo automatizar procesos, tarde o temprano llega a dos nombres: Make y n8n. Ambas permiten conectar aplicaciones, mover datos entre sistemas y armar flujos que antes requerían horas de trabajo manual.

El problema es que la mayoría de las comparativas que encontrás online las escribe alguien que probó las dos en un tutorial de YouTube, no alguien que las deployó en producción con un cliente real. Nosotros usamos n8n en producción (en un ERP a medida y en un sistema de automatización de prospectos comerciales) y Make lo evaluamos en detalle antes de descartar o elegir. Esto es lo que vimos.

Primero, de qué estamos hablando

Tanto n8n como Make son herramientas de automatización visual: te permiten conectar aplicaciones y definir flujos de trabajo sin escribir código (o con muy poco). El concepto es el mismo: cuando pasa X, hacé Y.

La diferencia está en cómo están construidas, cómo se cobran y para qué tipo de empresa están pensadas. Y esa diferencia importa mucho más de lo que parece al principio.

Cuándo Make tiene sentido

Make es la herramienta correcta si tu empresa recién empieza a automatizar y el equipo no tiene perfil técnico.

La experiencia de usuario de Make es excepcionalmente buena para principiantes. En pocas horas podés tener un flujo funcionando sin haber configurado nada técnico. La interfaz es intuitiva, la documentación es clara y la curva de aprendizaje es corta.

También tiene sentido si los flujos que necesitás son simples y el volumen de operaciones es bajo. Una empresa que automatiza el alta de clientes nuevos, el envío de un email de bienvenida y la carga en una planilla puede funcionar perfectamente con Make sin que el costo sea un problema.

Make es una buena elección cuando:

  • El equipo que va a operar la herramienta no tiene perfil técnico
  • Los flujos son relativamente simples
  • El volumen de operaciones diarias es bajo o moderado
  • Querés algo funcionando rápido, sin infraestructura propia

Cuándo n8n tiene sentido

n8n empieza a ganar cuando la operación crece o cuando hay requisitos que Make no puede cumplir.

El costo escala distinto. Make cobra por operación, esto quiere decir que cada paso dentro de un flujo cuenta. Para una empresa que procesa cientos o miles de transacciones por día, ese modelo se vuelve muy caro muy rápido. n8n, en su versión self-hosted, no tiene ese límite: corrés en tu propio servidor y el costo es fijo, independientemente del volumen. Vimos esto de cerca en un sistema de distribución donde los flujos procesaban miles de movimientos diarios: con Make, el costo mensual hubiera sido prohibitivo.

La privacidad y el control de los datos. Con Make, los datos de tu empresa pasan por los servidores de un tercero. Para muchas empresas eso no es un problema. Para otras (especialmente las que manejan datos sensibles de clientes, información financiera o procesos críticos) es inaceptable. n8n self-hosted corre en tu infraestructura, con tu base de datos (nosotros usamos PostgreSQL), y los datos no salen de tu entorno.

La latencia en flujos síncronos. Hay procesos donde la velocidad de respuesta importa: un chatbot que responde en WhatsApp, una integración que le devuelve una confirmación al usuario en tiempo real, un flujo que tiene que reaccionar en milisegundos. Make introduce latencia porque los flujos corren en la nube de un tercero. n8n self-hosted, corriendo en un servidor tuyo cerca de la aplicación, es significativamente más rápido en esos casos.

La visibilidad cuando algo falla. Esto es algo que raramente aparece en las comparativas pero que en producción hace una diferencia enorme. n8n es muy visual para debuggear: podés ver exactamente en qué paso falló un flujo, qué datos entró, qué datos salió. Además tiene una cola de reintentos que se configura con facilidad. Por ejemplo, si una llamada a una API externa falla por un error momentáneo, n8n lo reintenta automáticamente. En un entorno de producción eso vale mucho.

El largo plazo y la sostenibilidad. n8n es open source y tiene un equipo activo detrás. Hace poco lanzaron la versión 2.0, lo que indica una plataforma que sigue evolucionando. También soporta conexiones con hardware e IoT, lo que lo hace útil en entornos de manufactura, logística o cualquier operación que tenga componentes físicos. No es solo una herramienta de "conectar apps": es una plataforma de automatización que puede crecer con la empresa.

En resumen, n8n tiene sentido cuando:

  • El volumen de operaciones es alto y el costo por operación de Make sería prohibitivo
  • Necesitás que los datos queden en tu propia infraestructura
  • Tenés flujos donde la latencia importa
  • Querés visibilidad real de lo que pasa cuando algo falla
  • El proyecto es de largo plazo y no querés depender de un proveedor externo

Lo que las comparativas genéricas no te dicen

De Make: el modelo de cobro por operación parece razonable cuando hacés los cálculos con volumen bajo. Pero si tu empresa procesa miles de transacciones por día (pedidos, movimientos de stock, registros de clientes, mensajes entrantes) el costo se multiplica de manera que puede sorprenderte. Además, si tenés flujos donde necesitás respuesta rápida, la latencia que introduce el hecho de que todo pase por servidores externos puede ser un problema real.

De n8n: requiere un perfil técnico para instalarlo y mantenerlo correctamente. El self-hosting implica que vos sos responsable del servidor, las actualizaciones y los backups. No es una herramienta que le des a alguien sin experiencia técnica y esperes que funcione sola. Si no tenés ese perfil en tu equipo, necesitás un proveedor que se encargue de eso.

Cómo decidimos en Eje Z

Cuando un cliente nos plantea la necesidad de automatizar algo, nuestra decisión no empieza por la herramienta. Empieza por entender el proceso: qué volumen tiene, qué tan crítica es la latencia, si los datos son sensibles, si el flujo va a crecer, si hay un equipo técnico que lo va a operar.

Con eso sobre la mesa, la elección casi siempre se define sola.

Usamos Make cuando el cliente necesita algo funcionando rápido, el flujo es simple y el volumen es bajo. Usamos n8n cuando el volumen es alto, cuando los datos no pueden salir de la infraestructura del cliente, o cuando el flujo es parte de un sistema mayor que estamos construyendo a medida.

No hay una respuesta universal. Hay una respuesta correcta para cada situación.

Antes de elegir una herramienta, entendé el proceso

El error más común que vemos es el inverso: la empresa elige la herramienta primero y después intenta adaptar el proceso a lo que la herramienta puede hacer. El resultado suele ser un flujo que funciona a medias, que nadie entiende del todo y que cuando falla nadie sabe cómo arreglar.

La automatización bien hecha empieza por mapear el proceso, entender el volumen real y definir qué pasa cuando algo sale mal. Eso es exactamente lo que hacemos en el Sprint de Arquitectura antes de escribir una línea de código o configurar un flujo.

Si estás evaluando automatizar algún proceso de tu empresa y no tenés claro por dónde empezar, hablemos.