Cómo conectar tu web con Make o Zapier sin crear una bomba de relojería

El cliente con 147 Zaps y 23 fallando en silencio

Una empresa nos pidió auditar sus automatizaciones. Tenía 147 Zaps en Zapier y 23 fallaban en silencio cada semana. Nadie sabía cuáles eran críticos para el negocio. La factura mensual superaba los 800 €. Y cuando intentaron pasarse a Make para ahorrar, descubrieron que los flujos estaban tan enredados que la migración llevaría meses.

Make y Zapier son herramientas legítimas, pero funcionan como la pistola de silicona caliente: ideales para prototipos rápidos, peligrosas para estructuras permanentes. La facilidad para crear flujos esconde lo difícil que es mantenerlos.

Qué son realmente estas herramientas

Make (antes Integromat) y Zapier son plataformas que conectan aplicaciones mediante flujos visuales: cuando pasa algo en una herramienta (llega un formulario, se paga un pedido), se ejecutan acciones en otras. Zapier es más sencilla; Make es más potente y flexible.

Las 2 cobran por uso: Zapier por «tareas» y Make por «créditos» (antes los llamaba «operaciones»), que en la práctica dependen de los pasos que se ejecutan en cada flujo. A bajo volumen son baratas. Con mucho volumen o con flujos complejos, se encarecen rápido.

Son herramientas de orquestación, no de procesamiento: delegan el trabajo en las APIs de los servicios conectados y, si uno falla, el flujo hereda el fallo.

Cuándo usar Make o Zapier (y cuándo no)

Casos adecuados:

• Prototipar integraciones rápido para validar si de verdad hacen falta.
• Flujos sencillos de 2 o 3 pasos entre servicios populares.
• Volumen bajo o moderado (como orientación, menos de 10.000 créditos o tareas al mes).
• Equipos sin desarrolladores que necesitan una solución inmediata.
• Procesos que cambian a menudo y necesitan iterar rápido.

Casos problemáticos:

• Lógica compleja con condiciones anidadas, bucles y gestión de errores.
• Flujos críticos para el negocio, donde una caída sale cara.
• Volumen alto (por encima de 100.000 créditos o tareas al mes), donde el coste se dispara.
• Integraciones con APIs poco comunes o inestables.
• Procesos que exigen transformaciones de datos complejas.

La regla general: si tu flujo tiene más de 10 pasos, necesita lógica condicional compleja o maneja datos sensibles, probablemente debería ser código y no no-code.

Antipatrón: la bolsa de nudos

Consiste en crear flujos cada vez más complejos sin reconocer que has superado la capacidad de la herramienta. Los síntomas:

• Flujos de más de 20 pasos con varias ramas condicionales.
• Pasos de código (JavaScript o Python dentro de Make o Zapier) para resolver lógica compleja.
• Flujos que llaman a otros flujos y crean dependencias circulares.
• Variables globales o almacenes temporales para mantener el estado entre ejecuciones.

Si has llegado aquí, estás forzando la herramienta. Es como usar Excel como base de datos: se puede, pero no se debe.

Solución: migrar a código. Un pequeño servicio en AWS Lambda o un script PHP en tu propio servidor puede sustituir 50 pasos de Zapier por código legible, versionado y que se puede probar.

Seguridad y datos sensibles

Make y Zapier tienen acceso a tus datos: de clientes, financieros y operativos. Conviene revisar 4 cosas.

Permisos de lectura y escritura. Muchas conexiones piden permisos de escritura cuando solo necesitan leer. Revisa los permisos (scopes) de cada conexión y quita los que sobran.

Datos en tránsito y en reposo. Estas plataformas procesan tus datos en sus servidores. ¿Dónde? ¿Durante cuánto tiempo se guardan? Zapier procesa los datos principalmente en Estados Unidos; Make ofrece la opción de alojar tu cuenta en servidores de la UE. Si manejas datos personales o información financiera regulada, comprueba que encaja con tus obligaciones del RGPD.

Credenciales compartidas. Las conexiones suelen usar claves de API o cuentas de servicio. Si alguien con acceso a Make o Zapier deja la empresa, ¿qué acceso conserva? Cuando haya cambios en el equipo, revisa los usuarios y rota las claves.

Registro de datos. Por defecto, las 2 plataformas guardan un historial de ejecuciones con los datos procesados: emails de clientes, datos personales, importes. Revisa las opciones de retención y privacidad de tu plan (en Make, por ejemplo, puedes marcar un escenario como confidencial para que no guarde esos datos). Casi nadie lo hace.

Costes: la trampa del escalado

El modelo de precios es adictivo a bajo volumen y doloroso a alto volumen.

Zapier cobra por tareas: cada acción que se ejecuta con éxito cuenta como una. Un flujo con 5 acciones que se ejecuta 1.000 veces al mes son 5.000 tareas. El plan gratuito incluye 100 tareas al mes, y los de pago suben de precio por tramos de volumen.

Make cobra en créditos: cada módulo que se ejecuta consume al menos 1, incluido el disparador que comprueba periódicamente si hay datos nuevos, aunque no los haya. Suele salir más barato que Zapier, pero la lógica es la misma: más pasos y más ejecuciones, más factura.

El problema: al crear un flujo casi nadie calcula el volumen real. Un formulario de contacto con tráfico medio, más el spam, más las comprobaciones periódicas, puede generar miles de créditos o tareas al mes. Lo que diseñaste en el plan gratuito, de repente, cuesta 150 € al mes.

Solución: estima el volumen antes de diseñar. Multiplica las ejecuciones previstas por los pasos y añade un margen. Si el flujo va a superar las 50.000 créditos o tareas al mes, evalúa alternativas como código propio o n8n autoalojado.

Dependencia del proveedor y migración

Los flujos de Zapier no se pueden importar en Make, y los de Make se exportan en un formato propio (blueprint) que solo entiende Make. Si suben precios, eliminan un plan o cambian sus condiciones, estás atrapado.

Cómo mitigarlo:

• Documenta los flujos con independencia de la herramienta: qué entra, qué sale y qué lógica se aplica. Sin esa documentación, cada flujo es una caja negra; lo contamos en detalle en el coste oculto de las automatizaciones mal documentadas.
• Para los flujos críticos, ten un plan de migración: cómo replicarlos en código si llega el momento.
• Valora alternativas como n8n, que puedes alojar tú mismo, para los flujos donde el control es prioritario.

Buenas prácticas para flujos robustos

Si decides usar Make o Zapier, hazlo bien:

1. Nombres descriptivos. «Zap #47» no sirve. «Formulario de contacto → CRM con deduplicación» explica qué hace.

2. Gestión de errores explícita. Define qué pasa si un paso falla: ¿reintentar?, ¿avisar a alguien? Fallar en silencio es lo más peligroso.

3. Historial de cambios. Las 2 guardan un historial de versiones básico, pero no es un control de versiones de verdad: no hay revisiones ni explicación de por qué se cambió algo. Anota los cambios a mano (las capturas de pantalla ayudan).

4. Pruebas sistemáticas. No des por hecho que funciona. Prueba con datos reales, con casos límite y con errores de API simulados.

5. Monitorización. Revisa el historial de ejecuciones con regularidad y configura alertas cuando la tasa de error supere un umbral.

6. Una responsabilidad por flujo. Un flujo hace una cosa. Si necesitas lógica compleja, plantéate si debería ser código.

Y recuerda que conectar sistemas a base de parches crea otro tipo de silo: lo explicamos en lo que una empresa gana cuando sus sistemas dejan de funcionar en silos.

Alternativas a considerar

Antes de comprometerte con Make o Zapier, evalúa:

n8n: herramienta de código disponible (con licencia fair-code, no estrictamente open source) que puedes alojar en tu propio servidor. Más barata a escala y con más control, a cambio de mantener tú la infraestructura.

Desarrollo a medida: para flujos críticos o complejos, un pequeño servicio en PHP, Python o Node es más mantenible, se puede probar y sale más barato a largo plazo. Cuesta más al principio, pero después solo pagas el alojamiento, una fracción de lo que cuesta un plan de pago de no-code.

Integraciones nativas: muchos CRM, pasarelas de pago y herramientas de email marketing se conectan entre sí sin intermediarios (HubSpot con Stripe, por ejemplo) o tienen plugins oficiales para WordPress y WooCommerce. Antes de montar un flujo, comprueba si ya existe.

Preguntas frecuentes

¿Make o Zapier?

Make es más potente y más barato, pero cuesta más aprenderlo. Zapier es más sencillo y más caro a escala. Para flujos complejos, Make. Para lo simple, Zapier.

¿Puedo usar estas herramientas en un e-commerce?

Para procesos auxiliares, sí: notificaciones, sincronizaciones sencillas de inventario, avisos al equipo. Para el proceso de pago, no: es demasiado crítico y el volumen puede ser alto.

¿Qué hago si un flujo falla constantemente?

Primero, identifica por qué: ¿ha cambiado una API?, ¿llegan datos inesperados? Después, decide si merece la pena arreglarlo o si debería pasar a código.

¿Cumplen estas herramientas el RGPD?

En general sí, pero revisa tu configuración: dónde se procesan los datos, qué guardan los historiales y si tienes firmado el contrato de encargo del tratamiento (artículo 28 del RGPD). Para datos muy sensibles, valora alojar n8n en tu propio servidor.

Conclusión

Make y Zapier son útiles en su sitio: prototipos rápidos, flujos sencillos, equipos sin desarrolladores. Pero tienen límites claros que muchos descubren tarde.

El riesgo principal no es la herramienta, sino la tentación de seguir usándola en casos cada vez más complejos donde ya no encaja. Reconocer ese punto de inflexión y migrar a una solución más robusta es sensatez, no fracaso.

Si tienes flujos en estas plataformas y quieres saber cuáles están bien, cuáles deberían migrarse y cómo hacerlo sin romper nada, escríbenos y revisamos tus integraciones contigo.