Cuándo usar n8n y cuándo escribir código

n8n es excelente como pegamento, pero un mal lugar para construir un producto, y saber cuál de los dos estás haciendo es toda la habilidad. Toda automatización empieza igual: un workflow rápido en una herramienta visual que te ahorra una tarde. La trampa es que esa misma herramienta que abarató la primera versión te convierte la décima en un problema, porque para entonces tus reglas de negocio viven dentro de cajitas que arrastras con el mouse, que ningún test puede ver ni nadie puede revisar en un diff. Esta guía te da una prueba clara de dónde está de verdad la línea entre n8n y código, un patrón para conservar la velocidad de n8n sin dejar la lógica atrapada adentro, y una migración paso a paso que puedes copiar. Vas a terminar pudiendo defender "esto va en n8n" o "esto va en código" con una razón, no con una corazonada.

01 · Antes de ubicarlo: ponle nombre al trabajo

Antes de decidir entre n8n o código, anota tres cosas sobre la automatización. De aquí salen de verdad las quejas de "n8n no escala": el trabajo nunca se analizó, así que terminó armado donde cayó el primer nodo.

• ¿Dónde está el valor, en los conectores o en el algoritmo? Si lo difícil es hablar con cinco servicios y reacomodar sus payloads, eso es trabajo de integración y para eso está hecho n8n. Si lo difícil es una decisión (qué camino tomar, qué precio aplicar, si aprobar o no) eso es trabajo de algoritmo y pide código.
• ¿Cuántas ramificaciones y cuánto estado tiene en realidad? Un flujo casi lineal (disparador, transformar, escribir, notificar) se lleva bien con un canvas. Las ramificaciones de verdad, con condiciones que te importan, estado que se acumula o reglas que se cruzan entre sí, son donde el canvas se te vuelve un enredo imposible de testear.
• ¿Cuánto tiene que durar y quién lo mantiene? Un sync desechable que alguien sin perfil técnico podría ajustar la semana que viene es una cosa muy distinta a una regla de precios que tiene que ser correcta durante años y pasar por revisión en cada cambio. La vida útil y de quién es la responsabilidad pesan tanto como la lógica.

Si puedes responder esas tres preguntas, la ubicación sale casi sola. Si no, ninguna herramienta te va a salvar. Solo vas a terminar culpando a la que elegiste.

02 · La línea: pegamento contra producto

Pon los dos trabajos uno al lado del otro. Son tipos de trabajo realmente distintos, y casi todo el dolor viene de hacer uno en la herramienta pensada para el otro.

Usa n8n cuando

• Estás conectando servicios: llega un webhook, transformas un payload, escribes en una hoja, mandas un mensaje.
• La lógica es casi lineal y el valor está en las integraciones, no en el algoritmo.
• Quieres cambiar el flujo sin un deploy, y tiene sentido que alguien sin perfil técnico lo ajuste.
• El costo de una corrida equivocada es bajo y se puede recuperar, como una notificación que no salió o una corrida que vuelves a disparar a mano.

Escribe código cuando

• La lógica tiene ramificaciones de verdad, estado y reglas que vas a tener que testear una y otra vez.
• Es el corazón de tu producto y se va a mantener durante años, no semanas.
• Lo necesitas en control de versiones, con su revisión, sus diffs y la posibilidad de revertir.
• Equivocarse sale caro: dinero, confianza, una decisión de seguridad o de cumplimiento.

La prueba más filosa zanja todos los casos dudosos: en el momento en que un workflow tiene un «if» cuyo resultado de verdad te importa, esa rama va en código y con su test. Enrutar un mensaje de Slack según el canal está bien en el canvas. Decidir si apruebas un reembolso, qué descuento le toca a un cliente o si un request está autorizado es una decisión, y las decisiones que te importan hay que testearlas, revisarlas y poder revertirlas, y nada de eso te lo da un canvas.

03 · El patrón que escala: orquesta, no decidas

El error es plantearlo como uno o el otro. La arquitectura que aguanta usa los dos, con una frontera limpia entre ellos: n8n orquesta, tu código decide. n8n se encarga del mundo exterior desordenado (disparadores, scheduling, reparto, hablar con una docena de APIs) y le pasa el control a tu código en cuanto aparece lógica de verdad.

Webhook -> n8n (valida, reparte, programa) -> llamada HTTP a tu API (la decisión) -> n8n enruta el resultado -> notifica / escribe / reintenta

En concreto, el reparto de tareas queda así:

• n8n se queda con los extremos. El cron, el webhook de entrada, el reintento cuando algo falla, el reparto de "manda esto a Slack y además agrégalo a la hoja". Es justo lo que hace bien, y reconstruirlo en código es esfuerzo desperdiciado.
• Tu API se queda con las decisiones. Cualquier cosa con una rama que te importa, estado que se acumula o una regla a la que le pondrías un test se convierte en un endpoint. n8n lo llama como a cualquier otro nodo HTTP y enruta según la respuesta.

Esta frontera es la que te da las dos velocidades a la vez: sigues cambiando la orquestación en el canvas sin un deploy, y sigues teniendo revisión, tests y la posibilidad de revertir en cada línea de lógica que importa.

04 · La migración paso a paso: sacar un «if» del canvas

Supón que tienes un workflow de n8n que procesa solicitudes de soporte que entran. Hoy tiene un nodo Function y un nodo IF que entre los dos deciden la prioridad: revisan keywords, el plan del cliente y cuánto lleva abierto el ticket, y luego enrutan a "urgente" o "normal". Esa rama, sin que nadie lo notara, se volvió una regla de negocio, y es imposible de testear e invisible para la revisión. Así la sacas adelante sin perder lo bueno de n8n.

1. Ponle nombre a la decisión y define su contrato. Entrada: los campos del ticket que n8n ya tiene (texto, plan, antigüedad). Salida: un veredicto, un objeto con «priority» y un «reason» corto. Anota ese contrato primero, porque es toda la interfaz.
2. Lleva la lógica a una función con su test. Saca las reglas de keyword/plan/antigüedad del nodo Function y ponlas en una función real en tu repo, y escribe tests para los casos que importan (un ticket de plan free con una keyword urgente, un ticket viejo en cualquier plan, el caso por defecto, el aburrido). Ahora la regla tiene nombre, diff y red de seguridad.

// priority.ts: la decisión, en código, con un test alrededor
export type Ticket = { text: string; plan: "free" | "pro"; ageHours: number }
export type Verdict = { priority: "urgent" | "normal"; reason: string }

export function classify(t: Ticket): Verdict {
  if (/caido|caída|no puedo entrar/i.test(t.text))
    return { priority: "urgent", reason: "keyword de caída" }
  if (t.plan === "pro" && t.ageHours > 4)
    return { priority: "urgent", reason: "incumple SLA de pro" }
  return { priority: "normal", reason: "default" }
}

3. Exponla como un único endpoint. Envuelve «classify» detrás de una ruta HTTP, por ejemplo POST /classify, que recibe el ticket y devuelve el veredicto. Sin integraciones, sin efectos secundarios, solo la decisión.
4. Reemplaza la lógica del canvas por una llamada. En n8n, borra los nodos Function e IF que tenían la regla y mete un nodo HTTP Request que llame a /classify. Conserva el IF de n8n, pero que ahora ramifique según el campo «priority» que devolvió la API en lugar de reimplementar la regla. n8n vuelve a lo que hace bien: enrutar según un valor que calculó otro.
5. Deja los extremos en n8n. El disparador del webhook, la notificación de Slack, el append a la hoja, el reintento, todo se queda. Moviste la única decisión que importaba y nada más.

05 · Errores comunes

La línea es simple. Las maneras en que la gente la cruza sin darse cuenta son siempre las mismas.

• Lógica que se va colando en los nodos Function. Un workflow crece de una expresión inofensiva a la vez, hasta que un nodo Function tiene cien líneas de reglas de negocio sin un solo test. Revisa cada cierto tiempo los nodos Function y Code, porque cualquiera con una rama que te importa es candidato a migrar.
• Creer que "sin deploy" sale gratis. Editar la lógica en vivo en el canvas se siente rápido, pero un cambio sin diff, sin revisión y sin test es un cambio que después no vas a poder entender. La comodidad es real para el pegamento y un lastre para las decisiones.
• Secretos y efectos secundarios en el canvas. Es tentador llamar una API de pago o destructiva directo desde un nodo. Mejor deja las acciones irreversibles o sensibles detrás de tu código, donde puedes meterles guardas, claves de idempotencia y un test, en vez de esparcirlas por todos los nodos.
• Irte a código demasiado pronto. El error de signo contrario: armar a mano webhooks, OAuth, reintentos y un scheduler porque "los ingenieros de verdad escriben código". Si el trabajo es de verdad pegamento entre servicios, n8n ya lo resolvió. Úsalo y gasta tu esfuerzo en la lógica que sí es tuya.

La conclusión honesta es que esto es una decisión de dónde poner las cosas, no una religión de herramientas. Pon el trabajo de integración donde brilla la herramienta de integración, pon las decisiones donde viven los tests y la revisión, y conéctalos con una sola frontera HTTP limpia. Hazlo y conservas la velocidad de n8n que te ahorra tardes para el pegamento, mientras la lógica que tiene que ser correcta durante años se queda en código, donde de verdad la puedes defender.