n8n vs Zapier vs Make: qué plataforma low-code escoger en 2026

Las tres dominan el low-code de integraciones. Pero el "elige la que prefieras" es perezoso: cada una encaja en perfiles distintos de PYME. Aquí va una comparativa concreta con casos de uso.

El panorama low-code en 2026: tres productos consolidados

La pregunta "Zapier, Make o n8n" se ha vuelto la decisión por defecto cuando una PYME quiere automatizar integraciones entre SaaS sin contratar desarrolladores. En 2026 las tres han madurado y se reparten el mercado con perfiles muy distintos. La respuesta perezosa "elige la que te suene mejor" sale cara: cada una está optimizada para un patrón de uso diferente y elegir mal cuesta 3-5x el precio razonable o un nivel de complejidad que tu equipo no podrá mantener.

Antes de elegir conviene contestar tres preguntas internas: (1) ¿qué perfil técnico tiene quien va a construir y mantener los flujos? (2) ¿cuál es tu volumen mensual previsto en operaciones/tasks? (3) ¿qué sensibilidad tienen los datos que vas a mover entre sistemas? Las respuestas a estas tres descartan dos de las tres opciones casi siempre.

La complejidad típica de PYME 2026: 5-25 flujos en producción, entre 5.000 y 100.000 operaciones/mes, datos comerciales y de facturación (no datos médicos ni financieros profundos), equipo de marketing o ventas como propietario funcional. En este escenario, las tres son viables pero una claramente domina según el contexto exacto.

Cuándo elegir Zapier: equipo no técnico y volumen bajo

Zapier sigue siendo el rey del UX low-code. Su propuesta de valor: cualquier persona con criterio puede construir un Zap en 10-20 minutos sin entender de APIs, autenticación o JSON. Esta facilidad tiene coste, pero para perfiles concretos es el precio correcto.

• Tu equipo no tiene perfil técnico: marketing, ventas, RRHH construyen y mantienen los flujos. No hay nadie capaz de leer un payload JSON.
• Tus integraciones son lineales: 1 trigger -> 1-3 acciones. Sin condiciones complejas, sin bucles, sin transformaciones de datos importantes.
• El volumen es bajo: menos de 10.000 tasks/mes en total.
• Necesitas integraciones nicho: Zapier tiene el catálogo más amplio (7.000+ apps en 2026), incluyendo herramientas de nicho que Make o n8n no cubren.

Pricing real de Zapier en 2026

• Free: 100 tasks/mes, 5 zaps. Útil solo para probar.
• Professional: 19,99 USD/mes por 750 tasks. Bajo coste pero limitante.
• Team: ~70 USD/mes desde 25.000 tasks. La realidad para PYME que usa Zapier en serio.
• Company: 100+ USD/mes desde 100.000 tasks. A este nivel ya conviene plantearse alternativa.

Cuándo Zapier deja de tener sentido

A partir de 50.000-100.000 tasks/mes o cuando los flujos tienen 5+ pasos con condiciones, Zapier se vuelve 2-3x más caro que Make y menos potente. Si llegas ahí, migrar.

Cuándo elegir Make: flujos complejos y mejor relación calidad-precio

Make (antiguo Integromat) es la opción más equilibrada para PYME con cierta sofisticación. Curva de aprendizaje más empinada que Zapier (2-4 semanas para dominarlo razonablemente) pero potencia muy superior. El editor visual con scenarios es el más expresivo del mercado.

• Flujos con ramificación, condiciones y bucles: routers, iterators, aggregators. La lógica que en Zapier requiere 5 zaps encadenados, en Make es un scenario único.
• Procesamiento de datos en masa: CSV con miles de filas, transformaciones, joins, agregaciones. Funciones nativas de manipulación de strings, fechas, números, JSON.
• Volumen medio-alto: el modelo de pricing por "operations" (cada step ejecutado) escala mejor que Zapier para flujos con muchos pasos.
• Necesitas integraciones de pago/finanzas: el módulo de Stripe, GoCardless, PayPal en Make es más completo que en Zapier.

Pricing real de Make en 2026

• Free: 1.000 operations/mes. Suficiente para probar de verdad.
• Core: 9 EUR/mes por 10.000 operations.
• Pro: 16 EUR/mes por 10.000 operations + features avanzadas.
• Teams: 29 EUR/mes por 10.000 operations + colaboración multi-usuario. Tier típico de PYME.

Curva de aprendizaje real

El primer flujo lleva 2-4 horas. El décimo flujo, 30 minutos. La diferencia es entender el modelo de operations, el manejo de errores y los modules visuales. Recomendamos curso oficial de 8-12 horas antes de meter Make en producción.

Cuándo elegir n8n self-hosted: soberanía y volumen ilimitado

n8n es la opción open source y ha crecido enormemente entre 2023 y 2026. Su versión self-hosted (Docker en tu servidor) ofrece un trade-off particular: requiere capacidad técnica para mantenerlo, pero te da soberanía total sobre datos y un coste fijo independiente del volumen.

• Tienes perfil DevOps interno o partner técnico: el coste real es del 100% por instalación + 8-16 horas/mes de mantenimiento (updates, monitorización, backups).
• Soberanía de datos crítica: datos clínicos, datos de RRHH sensibles, datos financieros sometidos a auditoría. Que pasen por servidor de Zapier (EEUU) es incompatible con tu compliance.
• Volumen muy alto: a partir de 100.000 operations/mes, n8n self-hosted en Hetzner (CPX21, ~10 EUR/mes) sale rentable por orden de magnitud frente a Zapier o Make.
• Necesitas extensiones personalizadas: n8n permite escribir nodos custom en JavaScript/TypeScript. Para integraciones con sistemas internos legacy, esto es decisivo.

Requisitos técnicos reales

• Conocimiento: Docker, Linux básico, gestión de variables de entorno, lectura de logs, configuración de reverse proxy con HTTPS.
• Infraestructura: VPS de 4-8 GB RAM (Hetzner CPX21/31 sale 10-20 EUR/mes en 2026), backup automático a S3-compatible, monitorización (Uptime Kuma o similar).
• Tiempo de setup inicial: 6-12 horas para desarrollador con experiencia previa.
• Mantenimiento mensual: 4-8 horas (updates, revisión de logs, ajustes de capacidad).

n8n Cloud como camino intermedio

n8n ofrece versión managed (n8n Cloud) desde 20 EUR/mes. Precio comparable a Make, con la ventaja de poder migrar luego a self-hosted exportando los workflows. Buena opción para empezar sin compromiso técnico.

Matriz comparativa: integraciones, seguridad y soberanía

Catálogo de integraciones nativas en 2026

• Zapier: 7.000+ apps. Líder absoluto en breadth. Incluye apps muy de nicho (SaaS verticales europeos, herramientas regionales).
• Make: 1.800+ apps. Buena cobertura de productivity, marketing, ventas, finanzas. Más profundas (más triggers/actions por app) pero menos apps únicas.
• n8n: 1.100+ nodos oficiales + community nodes. Buen catálogo en stack moderno (Notion, Airtable, herramientas devops). Cobertura más floja en herramientas tradicionales y verticales.

Soberanía y compliance

• Zapier: servidores en EEUU. Sometido a Cloud Act. Para datos sensibles europeos: problema. Ofrece DPA (Data Processing Agreement) RGPD pero no resuelve el debate de soberanía.
• Make: servidores en UE (datacenter en República Checa). Mejor para compliance europeo. RGPD nativo.
• n8n self-hosted: en tu servidor, tu jurisdicción, tu control. Máxima soberanía. Necesitas elegir provider europeo (Hetzner, OVH) para conservar la ventaja.
• n8n Cloud: servidores europeos. Equivalente a Make en términos de soberanía.

Modelo de pricing por uso típico de PYME (10 flujos, 30.000 operations/mes)

• Zapier: 70-100 USD/mes.
• Make: 29-50 EUR/mes.
• n8n Cloud: 20-50 EUR/mes.
• n8n self-hosted: 10-25 EUR/mes de infraestructura + 4-8 horas/mes de mantenimiento técnico.

Migración entre las tres: caminos y trampas

Los flujos NO son portables directamente entre Zapier, Make y n8n. Cambiar de plataforma implica rehacer cada flujo manualmente, aunque la lógica sea la misma. Los tiempos de migración típicos para 10-15 flujos:

• Zapier -> Make: 20-40 horas. Make es más expresivo, así que muchos flujos se simplifican en el proceso.
• Zapier -> n8n: 30-60 horas. Salto más grande porque n8n requiere más comprensión técnica.
• Make -> n8n: 20-40 horas. Modelos mentales similares (scenarios vs workflows), pero sintaxis distinta.
• De cualquiera a otro: aprovecha la migración para auditar qué flujos siguen aportando valor. Suele haber 20-30% de flujos legacy que ya no se usan.

Trampas habituales en la migración

• Olvidar credenciales: cada flujo tiene auth a varios servicios. Documenta antes de migrar.
• No replicar el error handling: los flujos en producción tienen lógica de reintentos y notificación. Trasladarlas es 30-40% del coste.
• Cortar el flujo viejo antes de validar el nuevo: mantén ambos en paralelo 1-2 semanas para detectar discrepancias.
• Subestimar el rate limiting: los servicios de destino pueden bloquear tu integración si el patrón cambia bruscamente. Avisa a los vendors críticos.

Errores frecuentes en la elección

• Elegir Zapier porque "es el más conocido": para volumen mediano-alto sale 2-3x más caro que Make sin aportar valor.
• Elegir n8n self-hosted sin DevOps: el primer fallo crítico en producción descubre que nadie sabe arreglarlo. Coste real (técnico subcontratado) acaba siendo superior al de Make o Zapier.
• Elegir Make sin considerar curva de aprendizaje: equipos comerciales puros se frustran. El primer admin debe ser perfil tech-savvy (ops, marketing técnico).
• Mezclar las tres sin razón: vemos PYMEs con Zapier para algunos flujos, Make para otros, n8n para experimentos. Resultado: nadie sabe qué flujo está en qué herramienta cuando algo se rompe. Consolida en una.
• No documentar los flujos: cuando el constructor original se va, los flujos en producción son cajas negras. Documenta cada flujo con propósito, trigger, output y owner.
• No monitorizar errores: un flujo que falla en silencio pierde datos durante semanas. Configura alertas a Slack/Teams para fallos en cualquiera de las tres plataformas.

Preguntas frecuentes