n8n vs Make vs Zapier: la comparación se decide en cómo cobran

Puedes ignorar el 80 % de las tablas comparativas si entiendes esto.

Zapier cobra por tarea. Cada acción ejecutada cuenta; el disparador y los pasos internos de filtro o formato, no. Un flujo de doce pasos consume alrededor de nueve unidades cada vez que corre.

Make cobra por operación. Parecido, con dos diferencias: el precio por unidad es bastante más bajo y aquí sí cuenta el módulo disparador, incluidos los sondeos que no encuentran nada nuevo y un editor que permite hacer más con menos pasos.

n8n cobra por ejecución del flujo completo. Un flujo de tres nodos y uno de cuarenta consumen exactamente lo mismo: uno.

La consecuencia es enorme y se nota justo cuando el proyecto empieza a funcionar bien. Imagina un flujo que procesa cada lead que entra con ocho pasos, y que recibes mil leads al mes.

• En Zapier: unas siete mil tareas.
• En Make: unas ocho mil operaciones, a un precio por unidad menor.
• En n8n: mil ejecuciones.

Mismo trabajo, factura de otro orden. Y el efecto secundario importa más que el ahorro: cuando cada paso cuesta, la gente diseña flujos cortos para no gastar, y acaba con automatizaciones peores. Cuando el paso es gratis, añades la validación, el registro y el aviso de error que hacen que el flujo sea robusto.

Esto no significa que n8n gane siempre. Significa que el volumen y la longitud de tus flujos son la primera variable de la decisión, y no la lista de integraciones que ocupa la portada de las tres.

Zapier es la más fácil de las tres por un margen amplio, y tiene el catálogo de integraciones más grande de las tres, con varios miles de aplicaciones según su propia web.

Gana cuando:

• Quieres conectar dos aplicaciones conocidas y olvidarte. Formulario a hoja de cálculo, pago a correo, registro a lista.
• La persona que lo va a montar no es técnica y no quiere serlo.
• Necesitas una integración rara con una herramienta de nicho. Si existe en algún sitio, existe en Zapier.
• El volumen es bajo. Con cientos de tareas al mes, el modelo por tarea da igual.

Pierde cuando:

• El flujo tiene muchos pasos y corre muchas veces. La factura escala con el producto de ambos.
• Necesitas lógica de verdad: bucles, manejo fino de errores, transformaciones complicadas. Se puede, pero se pelea.
• Tus datos no pueden salir de tu infraestructura.

El resumen honesto: para una empresa pequeña con cinco automatizaciones sencillas, Zapier probablemente sea la decisión correcta y cambiarse a otra cosa sería optimización prematura. El problema de Zapier no es Zapier, es tener éxito con Zapier.

Make es más potente que Zapier y bastante más accesible que n8n. Su editor visual muestra el flujo como un diagrama y maneja estructuras de datos complejas mucho mejor.

Gana cuando:

• Los flujos tienen ramas, condiciones y transformaciones, pero no quieres tocar un servidor.
• El volumen es medio y el precio por operación de Zapier ya empieza a doler.
• Trabajas con datos anidados, listas dentro de listas, respuestas de API con estructura. Aquí es notablemente mejor que Zapier.

Pierde cuando:

• El volumen crece de verdad. Sigue cobrando por operación.
• Necesitas alojar los datos tú.
• Quieres escribir código para resolver algo que ningún módulo hace. Se puede algo, pero no es su terreno.

Dónde encaja de verdad: es la herramienta correcta para la mayoría de equipos de marketing y operaciones que ya se quedaron cortos con Zapier y no tienen a nadie que quiera administrar un servidor. Ese perfil es muy común y Make lo sirve bien.

n8n es la más flexible y la que más pide de vuelta.

Gana cuando:

• El volumen es alto o los flujos son largos. Aquí la diferencia de facturación es de orden de magnitud.
• Hay datos sensibles o requisitos de residencia que obligan a alojarlo tú.
• Necesitas escribir código en medio del flujo. Los nodos de JavaScript y Python resuelven lo que ningún catálogo cubre.
• Estás montando agentes de IA a medida, eligiendo qué modelo se usa en cada paso.
• Quieres conectar un sistema propio o antiguo que ninguna de las tres trae de serie.

Pierde cuando:

• No hay nadie que pueda mantenerlo. Este es el punto que hunde más proyectos, y no es técnico: es de organización.
• Necesitas una integración exótica ya hecha. El catálogo es menor, aunque el nodo de peticiones HTTP cubre casi todo si estás dispuesto a leer documentación.
• La persona que va a construir no quiere entender cómo viajan los datos entre nodos.

La pregunta que decide n8n no es técnica: ¿quién lo arregla un viernes por la tarde si se rompe? Si la respuesta es "nadie" o "ya veremos", elige otra cosa aunque salga más cara. Un flujo roto que falla en silencio cuesta más que cualquier suscripción.

Consultora de cinco personas, quiere que los formularios de la web lleguen al CRM y avisen por chat. Zapier, o directamente nada: mira antes si tu CRM ya lo hace. Este caso no justifica ninguna herramienta nueva.

Agencia con quince clientes y reportes semanales de cada uno. Make. Flujos con lógica, volumen medio, nadie quiere servidores. Y conviene mirar automatizar reportes de marketing con IA antes de construir.

E-commerce que sincroniza inventario con dos proveedores cada quince minutos. n8n. Es un flujo largo que corre miles de veces al mes: es exactamente el caso donde el modelo por tarea se vuelve absurdo.

Empresa que quiere un agente de IA en WhatsApp conectado a su ERP propio. n8n si hay perfil técnico dentro. Si no lo hay, una plataforma con el agente incorporado y una integración puntual hacia el ERP, porque el riesgo de que nadie pueda mantenerlo supera a la flexibilidad ganada.

Clínica que quiere recordatorios de cita y encuestas post-visita. Ninguna de las tres. Eso vive en el CRM donde ya está la ficha del paciente. Añadir una herramienta intermedia solo añade una pieza más que puede romperse.

Las tres tienen el mismo gasto invisible y es el que decide si el proyecto sobrevive: el mantenimiento.

Un flujo automatizado no es un activo estable. Cambian las APIs, caducan las credenciales, alguien renombra una columna, un servicio devuelve un formato distinto. Lo hace sin avisar y, si no montaste un aviso, el flujo falla en silencio durante semanas.

Las tres cosas que hay que tener sí o sí, en cualquiera de las tres herramientas:

• Un aviso cuando un flujo falla. A una persona, en un canal que esa persona mire.
• Un dueño con nombre. Alguien responsable de revisar que sigue haciendo lo que se supone.
• Una nota de qué hace y por qué existe. En seis meses nadie se acordará, y menos si esa persona ya no está.

Y donde el costo cambia de verdad entre herramientas: si alojas n8n tú, sumas mantenimiento de servidor, actualizaciones y copias de seguridad. Es perfectamente asumible si ya tienes infraestructura y alguien que la cuida. Es una trampa si tu equipo son tres personas de marketing y el servidor lo montó alguien que ya no está.

Vale la pena contarlo: hemos visto migraciones a n8n motivadas por ahorrar en suscripción que acabaron costando más en horas de puesta a punto de lo que ahorraban en licencia al año. El ahorro en licencias solo es real cuando el tiempo de quien mantiene vale poco o ya está pagado.

Responde en orden y para en la primera que aplique.

1. ¿Tu CRM o tu plataforma ya lo hace? Entonces hazlo ahí. Menos piezas, menos fallos, cualquiera del equipo lo toca. Este paso descarta una buena parte de los proyectos y es el que más dinero ahorra.

2. ¿Tienes datos que no pueden salir de tu infraestructura? Entonces n8n alojado por ti, y el resto de la discusión sobra.

3. ¿Tus flujos correrán más de unas pocas miles de veces al mes con varios pasos cada uno? Entonces n8n, si tienes quien lo mantenga. Si no lo tienes, Make y asume el costo.

4. ¿Necesitas lógica, ramas y datos anidados? Make.

5. ¿Nada de lo anterior? Zapier. Es el más caro por unidad y el que menos tiempo te va a costar, y ese cambio suele ser bueno.

Y una recomendación de método por encima de la herramienta: monta el primer flujo en la más simple que sirva, aunque sepas que te quedará corta. Vas a aprender más del proceso real en dos semanas de flujo funcionando que en dos meses eligiendo plataforma. Migrar un flujo que ya entiendes es fácil; entender un proceso que nunca automatizaste, no.

En Minimal montamos estas cadenas y las conectamos con los agentes que atienden la parte conversacional, dentro del CRM siempre que se puede. Si quieres que alguien decida esto con tu operación delante, cuéntanos qué proceso quieres automatizar.