Contratar un desarrollador de n8n, qué pedirle y qué preguntarle (2026)

Automatización

12 de octubre de 202613 min read

Miguel Ángel Rodríguez (Miguelo DEV)Especialista en automatización de procesos con n8n

Ya has decidido que automatizas con n8n y que quieres a una persona, no a una agencia. Lo difícil empieza ahora, que es distinguir entre los diez perfiles que te han escrito diciendo exactamente lo mismo.

El problema no es que mientan. Es que n8n tiene una curva de entrada muy suave y una curva de operación muy dura. Montar un flujo que funciona en la demo lo hace cualquiera en una tarde. Que siga funcionando en marzo, cuando la API del proveedor cambia y tú estás de vacaciones, es otro oficio.

En qué se nota que contratas a un desarrollador de n8n y no a alguien que arrastra nodos

Se nota el día que n8n no llega. Y no llega más a menudo de lo que parece. Una API que pagina con cursor. Una firma de petición que hay que calcular. Un fichero de ochenta mil filas que procesar sin comerse la memoria.

Los tres destrozos que más veces me ha tocado arreglar.

El flujo que da verde y no hace nada. Alguien puso un nodo en modo continuar en caso de error para que dejara de saltar la alerta, y desde entonces la ejecución se marca como correcta aunque la tarea no se haya hecho. Lo cuento entero en cuánto cuesta mantener automatizaciones de n8n al mes.

El flujo que duplica. El webhook no comprueba si ya ha visto ese identificador, el proveedor reintenta la entrega y acabas con dos pedidos y dos facturas.

El flujo que no se puede tocar. Cuarenta nodos en línea y la misma lógica repetida en seis sitios. Cambiar un campo cuesta medio día.

Las preguntas técnicas que filtran a un desarrollador de n8n en media hora

No necesitas saber n8n para hacerlas. Necesitas saber qué respuesta es buena y cuál te tiene que levantar de la mesa. Todas van de operación, no de nodos, y por eso funcionan.

¿Qué haces cuando un flujo en n8n falla y nadie lo está mirando?

Buena señal, que mencione un flujo de errores dedicado antes de que termines la pregunta.

Hay dos detalles que solo cita quien lo ha usado de verdad. Que ese flujo de errores no se puede probar en manual, porque el disparador solo salta en ejecuciones automáticas. Y que poner un nodo en modo continuar hace que el flujo termine correctamente, así que el flujo de errores no llega a dispararse.

Mala señal, lo miro por la mañana en el panel de ejecuciones. Y peor, poner todos los nodos en continuar para que no salten avisos. Eso no apaga el fuego, apaga la alarma de incendios.

¿Qué pasa si una API tarda en responder y cómo reintentas en n8n?

Buena señal, que se sepa los topes de memoria. La opción de reintentar al fallar está limitada por código a cinco intentos y cinco segundos de espera, y esa espera es fija. No existe reintento exponencial nativo, por mucho que circule lo contrario. Quien necesita espera creciente la construye aparte.

La otra mitad es saber qué no se reintenta. Un 401 por credencial caducada no mejora insistiendo. Quien reintenta todo igual convierte un error pequeño en un bloqueo de su cuenta en el proveedor.

¿Cómo evitas que el mismo webhook me cree dos veces el mismo pedido?

Buena señal, que use la palabra idempotencia sin que se la sugieras. Los proveedores reintentan las entregas cuando no reciben respuesta a tiempo, así que el mismo evento llega dos y tres veces.

La respuesta correcta tiene dos piezas. Una clave que venga del origen, normalmente el identificador del evento, y una comprobación de si ya se procesó antes del primer efecto secundario. Quien ha sufrido esto prefiere una tabla propia con restricción de unicidad.

Mala señal, decir que eso no pasa.

¿Cómo pruebas un flujo de n8n antes de ponerlo en producción?

Buena señal, que te avise de que los datos fijados en el editor se ignoran en producción. Según la documentación oficial de n8n, fijar la salida de un nodo solo se aplica a las ejecuciones manuales del editor. En cuanto el flujo corre publicado, el nodo vuelve a pedir datos reales.

Es un indicador precioso, porque esa trampa solo la conoce quien ha visto un flujo comportarse distinto al publicarlo.

Mala señal, probar en producción con un registro de prueba y borrarlo después. Funciona hasta el día que ese registro dispara una factura real.

¿Qué versión de n8n vamos a correr y cómo volvemos atrás si la actualización rompe algo?

Buena señal, que fije una versión concreta en lugar de correr siempre la última. Sin eso, cualquier reinicio del contenedor puede traer una versión distinta sin que nadie lo haya decidido.

Y aquí está la parte que casi nadie sabe. n8n aplica migraciones a su base de datos al arrancar y solo migra hacia delante. Volver a una versión anterior no es cambiar una etiqueta, es restaurar la copia de seguridad previa. Si el candidato lo dice sin que se lo preguntes, ha estado ahí.

¿Por qué crece la base de datos de ejecuciones de n8n y qué piensas hacer con ella?

Buena señal, que te corrija la premisa. n8n ya viene con la purga activada, con un tope de 336 horas de antigüedad y de 10.000 ejecuciones guardadas. Si la base de datos se te va de las manos, el motivo es otro.

Las causas reales son tres. Guardar la ejecución completa también cuando sale bien. Los binarios, que por defecto no van a disco. Y las ejecuciones anotadas, que no se purgan nunca.

Mala señal, con SQLite vamos bien. SQLite es el valor por defecto y sirve para empezar. En producción se usa PostgreSQL, y desde la versión 2 de n8n ni siquiera quedan alternativas.

¿Cuándo usas el nodo Code y cuándo te quedas en nodos nativos?

Buena señal, que defienda los nodos nativos por defecto y el código por excepción. Un flujo lleno de nodos de código solo lo mantiene su autor y pierde la ventaja de que n8n actualice la integración por ti.

Si vas a estar en n8n Cloud, pregunta por librerías. En la nube no se pueden instalar paquetes de npm dentro del nodo de código, solo hay un par disponibles de serie.

Mala señal, resolverlo todo en un nodo de código gigante. Suele venir de alguien que sabe programar pero no ha operado n8n nunca.

5 preguntas relámpago que se contestan en treinta segundos

1. En qué zona horaria corre la instancia. n8n viene por defecto en la de Nueva York. Si nadie lo cambia, un flujo programado a las nueve de la mañana se dispara a las tres de la tarde en España.
2. Qué diferencia hay entre la URL de prueba y la de producción de un webhook. Son dos direcciones distintas y la de prueba solo escucha mientras tienes el editor abierto.
3. Qué vocabulario usa. Desde la versión 2 los flujos se publican, ya no se activan. Quien hable del nodo Function está citando documentación retirada.
4. Cuándo montaría el modo de cola con Redis. La buena respuesta pregunta primero por el volumen. Para veinte flujos al día es sobreingeniería.
5. Qué pasa con las credenciales al pasar de pruebas a producción. El versionado con Git sincroniza flujos y nombres, nunca los valores de las credenciales.

Qué tiene que llevar tu briefing para que los presupuestos de n8n sean comparables

Si los presupuestos que recibes van de 600 a 6.000 €, el problema casi siempre es tu briefing y no los candidatos. Cuando el alcance es ambiguo, cada uno presupone otra cosa y comparar cifras no significa nada.

No es una manía mía. En el informe Pulse of the Profession del Project Management Institute, la recogida deficiente de requisitos aparece como la primera causa de fracaso de proyectos. Acotar es la única palanca gratis que tienes.

Los seis puntos que convierten un correo de tres líneas en algo cotizable.

1. El proceso contado de principio a fin, con quién lo hace hoy y cuánto tarda. No la solución que has imaginado, el problema.
2. Los sistemas concretos y su plan contratado, porque la API disponible cambia según el plan.
3. El volumen y los campos. Ejecuciones al día, picos y un ejemplo real anonimizado de lo que entra y lo que sale.
4. Qué pasa cuando algo falla. Si puede esperar a mañana o hay que avisar en cinco minutos. Mueve el precio más que el número de flujos.
5. El criterio de aceptación, escrito como una lista comprobable.
6. Quién mantiene esto a partir del mes dos, aunque todavía no lo sepas.

El quinto es el que más se salta la gente y el que más discusiones ahorra. Uno bueno suena a trescientos pedidos de prueba entran y salen con los mismos importes. Uno malo suena a que funcione bien.

Cómo pedir una prueba técnica de n8n que sea corta, justa y que de verdad discrimine

Una o dos horas, pagada, con enunciado cerrado y criterios entregados antes de empezar.

En una encuesta de interviewing.io a unos setecientos ingenieros, más del 80 % cree que una prueba para casa no debería pasar de cuatro horas y la duración preferida son dos horas. El 58 % opina que debería pagarse y solo al 4 % se la han pagado alguna vez. Y el dato que de verdad importa, no apareció relación alguna entre la calidad del candidato y su disposición a hacerla.

Mi encargo favorito cabe en un párrafo. Recibe un webhook con un pedido, valida los campos obligatorios, consulta un precio en una API pública, escribe el resultado en una hoja de cálculo y avisa por correo cuando algo falla.

Lo que evalúas no es que funcione, eso lo consiguen todos. Evalúas lo que ha puesto sin que se lo pidieras. Qué hace cuando falta un campo. Si reintenta la llamada. Si comprueba que el mismo pedido no se escribe dos veces.

Qué entregables exigir y qué señales de alarma tiene una propuesta de n8n

Lo que no está escrito en la propuesta no está en el precio, y lo descubres el día del traspaso.

Un matiz sobre la primera fila. Exportar los flujos no es hacer una copia de seguridad de tu n8n. El export no lleva el historial de ejecuciones, ni las variables, ni las claves que hacen legibles tus credenciales. Eso se respalda y se entrega aparte.

Las señales de alarma en la propuesta son más fáciles de leer que cualquier currículum.

Precio cerrado sin fase de descubrimiento. Nadie cotiza una integración sin haber visto los datos reales. Quien lo hace mete colchón o te pide ampliación en la semana dos.

Ni una palabra sobre errores ni sobre mantenimiento. Una propuesta que solo describe el camino feliz describe la mitad del trabajo.

Todo alojado en la instancia del proveedor. Si tu operación vive en el servidor de otro, irte cuesta un proyecto entero. Los motivos legales y de licencia los desarrollo en freelance de n8n o agencia.

Plazos sin dependencias. Prometer dos semanas sin mencionar que necesita accesos, datos de ejemplo y a una persona tuya para validar es prometer un retraso.

Cómo comprobar la experiencia real en n8n de alguien cuyo código de cliente no puedes ver

Pide un flujo anonimizado y mira dónde está el manejo de errores, no lo que hace el flujo. Es la comprobación más barata y la más certera.

Un flujo que ha estado en producción tiene cicatrices. Validaciones que alguien añadió después de un susto, una salida de error que va a un canal de avisos, un nodo que no hace nada salvo registrar qué llegó. Un flujo de tutorial va del disparador al resultado en línea recta y es precioso.

Hay un detalle que además te dice si la persona es cuidadosa. Un flujo exportado no lleva los secretos, pero sí lleva los nombres de las credenciales. Quien te manda el JSON avisando de que lo ha revisado ya te ha contestado media entrevista.

Después quedan dos vías más. Su rastro público, que son sus plantillas en la librería de n8n y su historial en el foro de la comunidad, difícil de inflar porque todo lleva fecha. Y referencias con una pregunta concreta, que no es si quedaron contentos sino qué se rompió y cuánto tardó en arreglarlo.

Cuándo no necesitas contratar a un desarrollador de n8n

Te lo digo aunque juegue en mi contra, porque me ahorra proyectos que no tenían que existir.

Cuando el proceso todavía no está decidido. Automatizar algo que vas a cambiar en dos meses es pagar dos veces. Escríbelo, córrelo a mano cuatro semanas y luego llámame.

Cuando son dos flujos sencillos entre herramientas con integración nativa. Eso lo monta tu equipo en una tarde. Contratar a un desarrollador para eso es llamar a un arquitecto para colgar un cuadro.

Cuando lo que tienes es un problema de datos. Si tus registros están duplicados y tus sistemas no se entienden, automatizar encima solo reparte el desorden más rápido. Primero se arregla el origen.

Cuando lo que te han vendido es un agente de IA y nadie sabe qué decide. Gartner publicó en junio de 2025 que más del 40 % de los proyectos de IA agéntica se cancelarán antes de que acabe 2027. Si el candidato empieza por el agente y no por el proceso, el proyecto ya nació torcido.

Cómo filtro yo a quien va a tocar automatizaciones que están en producción

No miro el portafolio. Miro cómo se comporta cuando algo no está documentado, que es el estado natural de cualquier integración real.

Le doy un flujo roto y le pido diagnóstico, no arreglo. Quince minutos. Me interesa el orden en que mira las cosas. Quien va primero al historial de ejecuciones y al dato que entró ha depurado antes.

Le pregunto por el peor incidente que ha tenido y qué cambió después. La segunda mitad es la que importa, porque un incidente que no cambió nada no se aprendió.

Le pido una decisión suya que resultó equivocada. Quien no tiene ninguna, o no ha mantenido nada suyo más de seis meses, o no te lo va a contar.

Miro si pregunta por el volumen y por qué pasa si falla. El que presupuesta sin preguntar eso está presupuestando otra cosa distinta de la que necesitas.

Yo soy desarrollador antes que consultor de automatización, con más de siete años construyendo producto para empresas como Kaspersky o Aave. Eso se traduce en dos cosas aburridas y muy útiles. Que cuando n8n no llega escribo el código que falta en lugar de decirte que no se puede. Y que cuando algo falla leo el registro en vez de rehacer el flujo entero a ver si hay suerte. Cómo planteo un proyecto completo lo cuento en automatizaciones con n8n.

Si te quedas con una sola idea, que sea esta. Contratar bien en n8n no va de encontrar a quien conozca más nodos, va de encontrar a quien ya haya sufrido lo que te va a pasar a ti.