Por Qué Dejé de Usar n8n y Make (Aunque Son Buenas Herramientas)

Esto me va a ganar algunos enemigos.

Llevo meses recomendando n8n y Make. Las he mencionado en mis videos. Están en mi futura guía de automatización.

Y sin embargo, yo casi no las uso.

No porque sean malas. Son excelentes para lo que fueron diseñadas. Pero después de construir decenas de automatizaciones, me di cuenta de algo incómodo:

Para alguien técnico, son más lentas, más caras, y más frágiles que escribir código.

Déjame explicarte.

El problema no es la herramienta, es el caso de uso

Make y n8n son perfectas para:

• Personas no técnicas que quieren automatizar

• Visualizar cómo fluyen los datos

• Prototipos rápidos

• Principiantes aprendiendo lógica de automatización

Pero si ya sabes programar, estás intercambiando velocidad por... ¿qué exactamente?

5 razones por las que ya no construyo en plataformas visuales

1. Es más lento que escribir código

Suena contraintuitivo, pero es verdad.

Arrastrar nodos, configurar cada campo en un modal, hacer click, click, click... vs escribir 20 líneas de Python que hacen lo mismo.

Un script que llama a una API, procesa datos y guarda en una base de datos me toma 10 minutos en código. En n8n me toma 30-40 minutos entre configurar nodos, probar, ajustar.

Y eso sin contar el debugging.

2. Debugging es una pesadilla

Algo falló en tu flujo de 15 nodos. ¿Dónde?

En código: pones un print, ves el error, lo arreglas.

En n8n/Make: abres cada nodo, revisas el output, tratas de entender qué dato llegó mal, rezas. Y eso porque el nodo en el que fallo no siempre es el que tiene el problema.

Cuando tienes lógica compleja con condicionales y loops, encontrar el bug puede tomarte horas.

3. Vendor lock-in real

Tu automatización vive en su plataforma.

¿Quieres cambiar de n8n a Make? Reconstruye todo. ¿Quieres versionar en Git? n8n lo tiene, pero limitado y solo en planes pagados. Su propia documentación dice que “no deberías verlo como version control completo”. Make ni siquiera eso, es export manual de blueprints uno por uno. ¿Quieres hacer code review antes de deployar? No hay pull requests nativos. ¿Quieres rollback a la versión de ayer? Suerte.

Tu lógica de negocio está atrapada en JSONs propietarios que no controlas.

4. Los costos escalan horrible

Make cobra por operaciones. n8n cloud cobra por ejecuciones.

Cuando procesas 100 cosas al día, es barato. Cuando procesas 10,000, la cuenta duele.

Un script corriendo en una función serverless (Lambda, Cloud Functions) cuesta centavos por las mismas 10,000 ejecuciones.

5. La lógica compleja se vuelve espagueti

Un flujo con 5 nodos es hermoso y claro.

Un flujo con 30 nodos, 4 branches, loops anidados y error handling es un monstruo visual que nadie quiere tocar.

He visto flujos que parecen el mapa del metro de Tokyo. Buena suerte manteniéndolos.

Y ni hablemos de testing. ¿Unit tests para tus flujos? No existe.

Qué uso yo en su lugar

Para automatizaciones simples:

Google Sheets + Apps Script

Sí, en serio. Un spreadsheet con un script de 30 líneas que corre cada hora. Gratis, versionable, fácil de mantener.

Para automatizaciones con IA:

Claude Code + Agentes

Archivos .md que definen agentes. Sin UI, sin plataforma, sin vendor lock-in. Git push y listo.

Para automatizaciones complejas:

Python + APIs directas

Un script que hace requests a las APIs que necesito. Lo corro en Lambda, en un cron, o en mi servidor. Control total.

Para orquestación seria:

Temporal, Prefect, o simplemente scripts con buen manejo de errores

Si necesitas workflows complejos con reintentos, timeouts, y observabilidad real.

Cuándo SÍ recomiendo n8n/Make

No estoy diciendo que sean malas. Las recomiendo genuinamente para:

✅ Principiantes - Ver los datos fluir visualmente es la mejor forma de aprender

✅ No programadores - Si no sabes código, son tu mejor opción

✅ Prototipos - Para validar una idea en 20 minutos antes de construirla bien

✅ Equipos mixtos - Cuando no todos son técnicos y necesitan entender el flujo

✅ Integraciones simples - Conectar Typeform → Google Sheets → Email funciona perfecto

La pregunta que deberías hacerte

“¿Estoy usando una herramienta visual porque es mejor, o porque no me he dado el tiempo de aprender la alternativa?”

Si la respuesta es la segunda, considera invertir esas horas en aprender a hacer lo mismo con código.

A largo plazo:

• Vas a construir más rápido

• Vas a debuggear más fácil

• Vas a pagar menos

• Vas a tener control total

Lo que sé con certeza

n8n y Make son herramientas excelentes para el público correcto.

Pero si ya sabes programar, probablemente estás perdiendo tiempo y dinero usándolas para todo.

El no-code es un puente, no un destino.

Aprende a cruzarlo.

¿Controversial? Probablemente. ¿Mi experiencia real? 100%.

Dime en los comentarios: ¿Team no-code o team código puro?

Más contenido sobre IA y automatización: tiktok.com/@isaiscoding