Make vs n8n: cuál elegir según la madurez técnica de tu equipo

La decisión que en realidad estás tomando

Nadie llega a comparar Make y n8n por curiosidad. Llega porque el equipo está armando reportes a mano, copiando datos entre el CRM y una hoja de cálculo, o reenviando correos que deberían dispararse solos. Alguien dice “hay que automatizar esto” y la búsqueda te deja frente a dos nombres que aparecen una y otra vez: Make (antes Integromat) y n8n.

El problema es que la comparación se hace mal desde el inicio. Se comparan listas de integraciones, cantidad de “nodos” o capturas de pantalla del editor visual, y con eso se decide. Esa comparación no dice nada sobre lo que en realidad determina si la automatización sigue viva en seis meses: quién la va a mantener, dónde vive el dato que procesa, y qué tan grave es el día en que se cae a las tres de la mañana.

Make y n8n resuelven el mismo problema superficial (conectar sistemas y disparar acciones sin escribir una integración desde cero), pero parten de un modelo de operación distinto. Uno apuesta por la nube gestionada y el lienzo visual puro. El otro nace open source, permite self-hosting y deja meter código cuando el flujo visual no alcanza. Esa diferencia de fondo es la que hay que decidir, no cuál interfaz se ve más bonita en un video de YouTube.

Qué es cada plataforma, sin el discurso de venta

Make es una plataforma de automatización basada en “escenarios”: un lienzo visual donde cada módulo representa una acción (leer una fila, enviar un correo, llamar una API) y las conexiones entre módulos definen el flujo de datos. Es cloud-first: la operas desde su interfaz, en su infraestructura, y pagas según el volumen de “operaciones” que ejecuta el escenario. Su fuerza está en la curva de entrada baja y en un editor visual que hace fácil entender el flujo de un vistazo.

n8n es una herramienta de automatización de flujos de trabajo basada en nodos, con un núcleo open source. Se puede usar en su nube gestionada o instalarla en tu propia infraestructura (self-hosted), lo que cambia por completo quién controla los datos que pasan por ahí. A diferencia de Make, n8n deja escribir JavaScript o Python directamente dentro de un nodo cuando la lógica visual se queda corta, y permite construir nodos propios cuando ninguna integración lista cubre el caso.

Vale aclarar algo que se pierde en casi toda comparación: n8n también tiene una versión cloud gestionada, con precio por ejecución, muy parecida en la superficie a Make. La diferencia de fondo no es “nube versus self-hosted” en abstracto, es que n8n te deja elegir entre ambos modelos según cómo evolucione tu operación, mientras que Make te mantiene dentro de su nube sin esa salida. Esa opcionalidad vale más de lo que parece cuando el volumen crece rápido y el plan cloud empieza a doler en el bolsillo.

Las diferencias que de verdad mueven la decisión

Bajando del discurso de marketing, esto es lo que cambia entre las dos cuando el flujo ya está en producción y algo falla un viernes a las seis de la tarde:

• Dónde vive el dato: en Make el flujo corre en la infraestructura de la plataforma; en n8n puedes self-hostear y que el dato nunca salga de tu servidor, algo que pesa distinto si trabajas con datos de salud, legales o financieros.
• Modelo de precio: Make cobra por operaciones ejecutadas dentro del escenario; n8n en su versión self-hosted no cobra por ejecución, pero el costo se mueve al servidor, el mantenimiento y quien lo administra.
• Curva de aprendizaje del equipo: Make se aprende arrastrando módulos y leyendo el flujo como un diagrama; n8n hace lo mismo, pero en cuanto la lógica se complica empuja a escribir código, lo que exige un perfil más técnico en el equipo.
• Extensibilidad real: cuando la integración que necesitas no existe como módulo listo, en Make dependes de un webhook genérico o un módulo HTTP; en n8n puedes construir un nodo propio o resolverlo con una función de código dentro del mismo flujo.
• Quién opera el día a día: un escenario en Make lo puede mantener alguien de operaciones sin perfil de desarrollador; un flujo self-hosted en n8n necesita a alguien que entienda servidores, versiones y actualizaciones, o un proveedor externo que lo haga.
• Gobierno y control de versiones: n8n self-hosted permite integrarlo a tu propio control de versiones y ambientes de staging y producción; Make gestiona esto dentro de su propia nube, con menos margen para un pipeline de despliegue propio.
• Comunidad y soporte: Make tiene soporte comercial centralizado desde la plataforma; n8n combina soporte enterprise pagado con una comunidad open source activa, que resuelve rápido problemas comunes pero no reemplaza un contrato de soporte cuando el flujo es crítico.
• Resiliencia ante caídas del proveedor: si Make tiene una interrupción, el flujo se detiene sin que puedas hacer nada más que esperar; si el flujo corre self-hosted en n8n, la disponibilidad depende de tu propia infraestructura, para bien y para mal.

Cuándo encaja cada una en la práctica

Elige Make si...

• El equipo que va a mantener el flujo no tiene perfil técnico ni tiempo para aprender a administrar un servidor.
• El volumen de operaciones es predecible y cabe cómodo dentro de un plan mensual sin sorpresas de costo.
• Necesitas mostrar avances rápido: un piloto, una prueba de concepto, un proceso de un área que todavía no justifica infraestructura propia.
• El dato que procesas no tiene restricciones regulatorias fuertes que exijan que nunca salga de tu propio servidor.

Elige n8n si...

• Ya tienes, o vas a tener pronto, un perfil técnico interno que puede operar, versionar y actualizar el flujo como si fuera software.
• El dato que mueves es sensible (salud, legal, financiero) y el control sobre dónde se procesa es un requisito, no un extra deseable.
• El volumen de ejecuciones es alto y constante, al punto donde pagar por operación en un modelo cloud se vuelve más caro que operar tu propio servidor.
• El caso de uso necesita lógica que el editor visual no cubre bien: llamadas encadenadas complejas, transformaciones de datos no triviales, integraciones que no existen como módulo listo.

Errores comunes al decidir entre las dos

• Elegir por la interfaz más bonita en una demo, sin preguntar quién del equipo la va a operar en seis meses cuando la persona que la configuró ya no esté.
• Migrar a self-hosted en n8n para “ahorrar” en licencia sin contar el costo real del servidor, las actualizaciones y el tiempo de alguien manteniéndolo: el ahorro en papel se come en horas de operación.
• Quedarse en un plan cloud de Make con un volumen de operaciones que crece cada mes sin revisar si ya cruzó el punto donde self-hosted sale más barato.
• Automatizar un proceso que nadie mapeó primero: la herramienta ejecuta rápido un flujo mal diseñado, y el resultado es un error que se repite mil veces por minuto en lugar de uno solo al día hecho a mano.
• Tratar la elección como definitiva y para siempre: un equipo que empieza en Make porque necesita velocidad puede migrar partes críticas a n8n self-hosted más adelante, sin que eso sea un fracaso de la decisión inicial.

Cómo saber si la elección fue la correcta

La señal no es que funcione el primer día, cualquier automatización funciona el primer día. La señal real aparece a los 60 o 90 días de uso:

• El flujo sigue corriendo sin que la persona que lo construyó tenga que intervenir cada semana.
• El costo mensual (licencia, servidor, horas de mantenimiento) sigue siendo menor que el costo de la tarea manual que reemplazó.
• Cuando el flujo falla, alguien del equipo lo puede diagnosticar sin depender de una sola persona que “es la única que entiende eso”.
• El equipo puede escalar el mismo patrón a un segundo proceso sin rehacer la arquitectura desde cero.

Si a los tres meses la respuesta a cualquiera de esos puntos es no, el problema no es la herramienta: es cómo se implementó, y ahí conviene un diagnóstico del proceso antes de saltar a la otra plataforma pensando que va a resolver algo que en realidad es un tema de diseño, no de tecnología.

Mi criterio