n8n vs chatbot custom: cuándo el low-code se queda corto (guía para CTOs)

Si eres CTO o lideras decisiones técnicas en una empresa, este escenario te suena: el equipo de operaciones pide un chatbot para atender consultas internas. Investigas un poco y aparecen dos caminos. Uno rápido: n8n, plataforma low-code visual que monta workflows en horas. Otro lento: construirlo a medida con tu stack habitual (Django, Python, una vector database). El comercial de n8n te dice que es la opción moderna. Tu equipo de desarrollo dice que un custom les daría más control. Y tú tienes que decidir.

Este artículo te da los criterios concretos que usamos en cada proyecto. Sin marketing y sin elegir bandos: n8n es una herramienta excelente para lo que es, y desarrollo a medida también lo es para lo suyo. La pregunta no es cuál es mejor en abstracto, sino cuál encaja en tu caso real.

Qué es cada cosa, sin marketing

n8n es una plataforma de automatización low-code: defines workflows arrastrando nodos en una interfaz visual, y cada nodo hace una cosa (recibir un mensaje, llamar a una API, transformar un dato, llamar a un LLM). Tiene un amplio catálogo de integraciones nativas con servicios comunes (Slack, Notion, Google Workspace, CRMs, vector databases) y permite escribir código JavaScript en nodos custom cuando una integración no llega. Existe en versión cloud gestionada, cuyo precio depende principalmente de las ejecuciones mensuales de workflows (los planes incluyen usuarios y workflows ilimitados; una ejecución equivale a un workflow completo independientemente de su complejidad), y en versión self-hosted (Community Edition), donde asumes infraestructura, mantenimiento, actualizaciones y operación sin límites de ejecuciones. Para RAG en concreto, soporta vector stores nativos como Pinecone, Qdrant y pgvector, reranking, AI Evaluations e integración con LangChain.

Un chatbot custom es código escrito por tu equipo. Backend en Django (o FastAPI, o Node), vector database (pgvector, Qdrant, Pinecone, Cloudflare AI Search), acceso a APIs de LLMs (OpenAI, Anthropic, Llama autohospedado) y un frontend para la conversación. Cada decisión técnica es tuya. Cada línea de código vive en tu repositorio. Puedes decidir qué datos pasan por tu infraestructura, qué servicios externos usas y qué partes mantienes bajo control propio.

Los dos enfoques resuelven el mismo problema —construir un asistente conversacional que responda a partir de información tuya— pero el resultado, el coste a largo plazo y la flexibilidad son radicalmente distintos.

Lo que importa en la práctica

Esta tabla resume las diferencias que realmente afectan a la decisión:

Lo que esta tabla te dice en una frase: n8n permite llegar bastante lejos en chatbots empresariales, incluido RAG con vector stores y reranking. El custom gana cuando lo que necesitas es control de ingeniería: testing automatizado, gobernanza estricta, observabilidad granular y capacidad de optimización fina a largo plazo.

Cuándo elegir n8n

n8n es la opción correcta cuando se cumple alguna de estas condiciones:

• Volumen bajo o medio (cientos o miles de ejecuciones al mes; en self-hosted, el límite práctico lo marca tu infraestructura, mantenimiento y arquitectura de colas/workers)
• Lógica de negocio que encaja en un grafo de workflow (FAQs, derivaciones, integraciones directas, RAG empresarial sobre documentación interna)
• Quieres validar el caso de uso antes de invertir en desarrollo
• El equipo de operaciones puede mantener el workflow sin pedir horas a desarrollo cada cambio
• Las integraciones que necesitas ya existen en el catálogo de nodos (o las puedes resolver con el nodo Code)
• El presupuesto inicial es ajustado y prefieres una iteración rápida a una inversión grande de entrada
• Soberanía de datos sin equipo técnico de plantilla: la opción self-hosted te da control de la infraestructura sin tener que construir el chatbot desde cero

Para un FAQ-bot de RRHH sobre políticas internas, n8n cumple sobrado. Para un asistente que automatiza derivaciones a comerciales en horario laboral, también. Para un RAG sobre documentación corporativa con cientos o miles de documentos, n8n bien configurado puede funcionar perfectamente. La regla mental que usamos: si el problema cabe en un grafo razonablemente legible y no requiere testing automatizado del pipeline, n8n suele ser una buena respuesta.

Cuándo elegir custom

El desarrollo a medida gana cuando entra en juego alguno de estos factores:

• Control de ingeniería profundo: versionado de prompts, testing automatizado, trazabilidad por documento, pipelines reproducibles
• RAG sobre miles de documentos cuando necesitas controlar al detalle chunking, búsqueda híbrida, reranking, permisos por documento, evaluación, trazabilidad y observabilidad
• Gobernanza estricta: auditoría completa, segregación granular de permisos por documento o departamento, compliance regulado
• Datos sensibles que no pueden pasar por servicios externos (banca, salud, defensa, datos personales críticos)
• Volumen alto sostenido donde el coste por ejecución de n8n se vuelve significativo y self-hosting no compensa
• Latencia crítica donde necesitas optimizar el pipeline al detalle (infraestructura, workers, colas, caché)
• Integración profunda con tu stack (ERP propio, base de datos compleja, APIs internas con auth peculiar, lógica de negocio que no encaja en un grafo de nodos)
• Evolución a largo plazo con cambios frecuentes que requieren testing, CI/CD y refactor sin estar atado al ritmo de releases de un vendor

En proyectos donde el chatbot es una pieza estratégica del producto, no una herramienta auxiliar, custom suele ser la opción más defendible desde el primer día.

El coste real que casi nadie cuenta

Una conversación habitual con clientes:

— “n8n cloud Starter cuesta unos 20 euros al mes. Custom me cuesta 10.000 € de desarrollo. Es evidente que sale más barato.” — “¿Cuántas conversaciones al mes estimas?” — “Unas 500.” — “¿De cuántos mensajes por conversación?” — “No sé… 8-10 mensajes de media.” — “Entonces son 4.000-5.000 mensajes. ¿Y dentro de un año?” — “Si funciona… probablemente el triple.”

Aquí aparece el primer cálculo que se suele simplificar. En un chatbot construido con n8n, cada mensaje al Chat Trigger ejecuta el workflow completo: 1 mensaje = 1 ejecución. Una conversación de 10 mensajes consume 10 ejecuciones, no 1. Con 500 conversaciones de 10 mensajes ya estás en 5.000 ejecuciones al mes — el plan Starter (2.500 ejecuciones) se queda corto y pasas al Pro, y si crece más, al Business o al self-hosted. Esto no convierte n8n en mala opción: simplemente hay que hacer el cálculo con la métrica correcta.

Y hay un cálculo aún más importante que suele faltar en ambos lados de la decisión. Tanto si eliges n8n como custom, vas a pagar:

• Llamadas al LLM (OpenAI, Anthropic, Gemini): el grueso del coste variable a escala
• Embeddings para indexar y consultar tu base de conocimiento
• Vector database (Pinecone, Qdrant, pgvector, Cloudflare AI Search…)
• Observabilidad y logging (Datadog, Sentry, o equivalentes)
• Seguridad y compliance (gestión de secretos, segregación de datos, auditoría)

Estos costes son comparables en ambos enfoques. La diferencia no está en si los pagas, sino en qué grado de control tienes sobre cómo se optimizan. Con custom puedes implementar cachés, batching, modelos propios, estrategias de retrieval específicas o cambiar de vector DB sin rehacer el workflow. Con n8n cloud, la optimización está acotada por lo que el engine permite.

El coste estratégico sí marca diferencia:

• Atado al ritmo del vendor en cloud: cambios de pricing, deprecación de nodos, condiciones de uso
• Optimización fina: con custom puedes ajustar latencia, consumo de tokens y arquitectura; con n8n vives con lo que el engine te da
• Gobernanza de datos sensibles: el self-hosted de n8n te da soberanía, pero hereda la complejidad de mantener tu propia infraestructura

Esto no convierte n8n en una trampa. Para muchos casos, los trade-offs son perfectamente aceptables a cambio de la velocidad inicial. Lo importante es calcularlos conscientemente con la métrica correcta (ejecuciones por chat, no conversaciones), no compararlos con un cliché.

Cómo decidimos nosotros en un proyecto

Cuando un cliente nos pregunta cuál usar, hacemos estas preguntas en orden:

1. ¿El chatbot es estratégico o auxiliar? Si es auxiliar (FAQ interno, derivaciones simples), n8n. Si es estratégico (interfaz principal con clientes, parte del producto), custom.

2. ¿Cuánto volumen esperas en 12-18 meses? Si caben en el plan medio de n8n cloud, sigue siendo viable. Si lo superas, calcula el coste y compáralo con desarrollo custom.

3. ¿Los datos pueden salir de tu infraestructura? Si no (compliance, sector regulado, datos personales sensibles), o bien n8n self-hosted con todo el coste de mantenimiento, o directamente custom.

4. ¿Vas a necesitar lógica que no quepa en un workflow visual? Si ya sabes que sí, no esperes. Cualquier hora invertida en n8n para esa lógica acaba reescrita.

5. ¿Tu equipo tiene capacidad de mantener un custom? Si la respuesta es no y no quieres contratar, n8n es razonable aunque el resto de criterios apunten a custom.

En la mayoría de proyectos que evaluamos, n8n cubre bien las necesidades. El custom suele ser la respuesta cuando el chatbot es estratégico, hay datos sensibles, o se necesita gobernanza estricta. Y en algunos casos, la combinación de empezar con n8n para validar y migrar a custom cuando el negocio lo justifique es la decisión más sensata.

La opción híbrida (que pocos consideran)

Hay una arquitectura intermedia que funciona muy bien: el chatbot custom como núcleo, n8n como capa de integraciones operativas.

El razonamiento conversacional (RAG, generación de respuesta, gestión de contexto) vive en código Django. Las integraciones secundarias (notificar a Slack cuando se deriva un caso, crear un ticket en Jira, actualizar un CRM) se gestionan con n8n, conectado vía webhook al backend custom.

Resultado:

• Control total sobre la conversación y los datos sensibles
• Velocidad de desarrollo para las integraciones periféricas que cambian con frecuencia
• Coste razonable porque n8n maneja volúmenes bajos (una integración por conversación, no cada turno)

Esta arquitectura combinada es la que mejor escala cuando el chatbot crece y el negocio cambia. No es lo más rápido de implementar, pero es lo más sostenible.

Conclusión: la decisión que sí depende del contexto

Si solo tuviéramos una recomendación general: empieza por entender tu caso, no por la herramienta.

n8n es brillante en lo que hace. Resuelve buena parte de los chatbots empresariales con menos esfuerzo que cualquier alternativa, y su soporte de RAG con vector stores, reranking y AI Evaluations cubre escenarios bastante avanzados. Si tu caso encaja, no busques complicarlo: úsalo, valida con usuarios reales, mide impacto. Si dentro de un año o dos resulta que necesitas más control, migras.

Custom es la respuesta cuando hay razones técnicas, estratégicas o de negocio que no se resuelven bien con un workflow visual: testing automatizado del pipeline, gobernanza estricta, observabilidad granular, optimización fina del rendimiento, o datos sensibles que no pueden depender de plataformas externas. Cuesta más al principio. Te da más control sobre cómo evoluciona el sistema y cómo optimizas los costes a largo plazo. Para casos donde el chatbot es parte del producto, no una herramienta auxiliar, esa inversión suele justificarse.

La peor decisión es elegir por moda, por discurso comercial o por prejuicio anti low-code. La buena es elegir por encaje real con tu volumen, tu complejidad y tu estrategia.