2. Constructor de workflows vs dueño del sistema

Descripción

Al terminar esta lección vas a poder explicar, con argumentos que resisten una entrevista, por qué "funciona en mi editor" no es un entregable que una empresa pueda pagar, y vas a saber exactamente qué artefacto te mueve de la categoría "constructor de workflows" a la categoría "dueño del sistema de automatización". Vas a conocer las preguntas concretas con las que un entrevistador te ubica en una u otra categoría, y qué respuesta te descarta en el primer minuto.

Esto importa porque el criterio de contratación es más binario de lo que parece. No es que el constructor gane menos que el dueño del sistema por hacer lo mismo con menos experiencia; es que buscan cosas distintas y compiten por vacantes distintas. La oferta que dice "build workflows" y la que dice "own our automation systems, delivered as version-controlled documented JSON" no son el mismo puesto con distinto sueldo: son dos puestos. Esta lección te enseña a leer de qué lado de esa línea está una vacante, y qué tienes que poder mostrar para calificar al lado que paga mejor.

Conexión con el módulo: en la lección 1 nombramos la distinción entre constructor y dueño del sistema, y la dejamos como un titular. Esta lección la vuelve operativa: la convierte en preguntas concretas, en un artefacto concreto y en una decisión de carrera concreta. Las lecciones 3 a 7 son, cada una, una pieza de lo que necesitas para pararte del lado del dueño del sistema: entender los límites del JSON suelto (3), su anatomía (4), qué se rompe al moverlo (5), el modelo mental que lo ordena todo (6) y qué cuesta cada cosa (7). Y la lección 8 te hace producir la primera versión del artefacto del que habla esta lección.

"Funciona en mi editor" no es un entregable

Piensa en dos personas que venden tacos.

La primera tiene un puesto en la esquina y hace unos tacos memorables. La receta está en su cabeza. El punto exacto de la salsa lo calcula con la mano, "hasta que se ve bien". Nadie más sabe hacerlos como ella. Mientras esté ella, parada frente a su comal, el taco es perfecto. El día que se enferma, el puesto cierra. El día que quiere abrir un segundo puesto, no puede: no hay forma de estar en dos esquinas a la vez, y no hay forma de enseñarle a otra persona una receta que solo existe en su intuición.

La segunda persona hace tacos igual de buenos, pero hizo algo más: escribió la receta con cantidades exactas, documentó el punto de la salsa con una medida que cualquiera puede repetir, y dejó por escrito el orden de cada paso. Ahora puede abrir cinco locales. Puede enfermarse un martes y el local sigue abierto. Puede vender el negocio, porque lo que vende no es "mis manos", es un sistema que funciona sin ella.

Las dos hacen tacos igual de buenos. Solo una de las dos tiene un negocio. La otra tiene un talento, que es una cosa admirable y frágil, atada a una sola persona y a un solo momento.

En automatización pasa exactamente lo mismo, y la frase que marca la diferencia es "funciona en mi editor". Cuando un constructor de workflows entrega su trabajo diciendo "ya está, funciona, míralo correr en mi n8n", está en la posición de la primera taquera: el sistema funciona mientras él esté, en su instancia, con sus credenciales cargadas a mano, y nadie más lo toque. Es un talento, no un entregable.

Un entregable es otra cosa. Un entregable es algo que una empresa puede recibir, operar sin ti, auditar y recuperar. Es la receta escrita, no el taco. En el mundo de n8n, ese entregable tiene un nombre que el mercado escribe casi con las mismas palabras cada vez: workflows as version-controlled, documented JSON —workflows entregados como JSON versionado y documentado—. Fíjate en cada palabra, porque cada una responde a una fragilidad del "funciona en mi editor":

• JSON: no es "míralo en mi pantalla", es un archivo que puedes entregar, que existe fuera de tu instancia.
• version-controlled: no es una foto suelta, es un historial con la capacidad de volver atrás y de coordinar a un equipo.
• documented: no es "pregúntame a mí por qué está así", es una explicación que sobrevive a que tú te vayas.

Un constructor produce workflows que funcionan. Un dueño del sistema produce ese entregable. La distancia entre los dos es justo lo que enseña esta guía, y es una distancia que se paga.

Ejemplo trabajado: la misma persona en dos entrevistas

Veamos la diferencia en acción, con un diálogo. Es el mismo candidato, con las mismas habilidades para construir workflows, respondiendo a dos entrevistadores distintos. Lo único que cambia es qué puede mostrar.

Entrevista A — el constructor.

Entrevistador: Veo que construiste un workflow que clasifica pedidos con un agente de IA y los manda al CRM. ¿Cómo lo desplegaste a producción?

Candidato: Lo construí en mi n8n, lo probé, y cuando funcionó lo activé.

Entrevistador: Supón que haces un cambio y rompe algo. ¿Cómo vuelves a la versión anterior?

Candidato: Tengo backups. Descargo el JSON cada tanto, así que podría reimportar uno viejo.

Entrevistador: ¿Y sabes qué cambió entre ese backup viejo y el actual?

Candidato: Tendría que abrir los dos y comparar a ojo… la verdad, no fácilmente.

Entrevistador: ¿Cómo pruebas un cambio sin que le escriba al CRM real de la empresa?

Candidato: Bueno… tendría cuidado de no activarlo hasta estar seguro.

Qué esperar de esa conversación: no llega a la segunda ronda. No porque no sepa construir —claramente sabe—, sino porque cada respuesta revela que el sistema depende de que él tenga cuidado, se acuerde y no se equivoque. La empresa no puede comprar "cuidado". Necesita garantías que existan fuera de la memoria de una persona.

Entrevista B — el dueño del sistema. Mismo candidato, después de esta guía.

Entrevistador: ¿Cómo lo desplegaste a producción?

Candidato: El workflow vive versionado en un repositorio Git. Lo desarrollo en un entorno dev con credenciales de prueba, lo pruebo en staging con datos parecidos a los reales, y cuando pasa las pruebas lo promuevo a prod. Cada paso queda registrado.

Entrevistador: Supón que un cambio rompe algo. ¿Cómo vuelves atrás?

Candidato: Vuelvo a la versión anterior del repositorio con un comando, porque cada versión quedó guardada con su fecha y su motivo. El rollback toma un minuto, y sé exactamente qué estoy revirtiendo porque puedo ver el cambio línea por línea.

Entrevistador: ¿Cómo pruebas sin tocar el CRM real?

Candidato: En dev y staging el workflow usa credenciales de una cuenta de prueba del CRM y datos sintéticos, así que puedo ejecutarlo todas las veces que quiera sin efectos sobre los datos reales. El CRM real solo se toca en prod.

Mismo talento para construir. Respuestas de otro planeta. La diferencia no es que el segundo candidato sea "más técnico"; es que puede describir un sistema operable, no un talento personal. Y todo lo que dijo —repositorio, entornos, credenciales de prueba, rollback— es exactamente el temario de esta guía.

Fíjate en algo importante: el entrevistador nunca le pidió que construyera un workflow. Dio por hecho que sabe. Todas sus preguntas fueron sobre operar, versionar, probar y recuperar. Esa es la conversación para la que esta guía te prepara, y es la conversación que decide el sueldo.

Las tres fragilidades del "funciona en mi editor", con order-triage

La frase "funciona en mi editor" suena inofensiva, así que vale la pena hacerla concreta. ¿Qué es, exactamente, lo que se rompe cuando un sistema depende de que todo esté "en tu editor"? Usemos el workflow de Cumbre, order-triage, que ya conoces: recibe pedidos, los clasifica con un nodo AI Agent y consulta el CRM por HTTP. Tiene tres fragilidades, y cada una es un módulo de esta guía.

Fragilidad 1: vive en un solo lugar y ese lugar es tu máquina. El workflow existe en la base de datos de tu instancia de n8n. No hay copia con historia en ningún otro lado. Si tu disco falla, si borras el workflow por accidente, si tu instancia se corrompe, no hay a dónde volver. Y aunque tengas un archivo order-triage.json bajado en tu carpeta de descargas, ese archivo es una foto de un momento, sin historia: no sabes qué tenía la semana pasada ni por qué cambió. Esta fragilidad la resuelve el versionado: el Módulo 2 (Git) y el Módulo 3 (exportar y estructurar el repositorio).

Fragilidad 2: no hay dónde probar sin romper lo real. order-triage le escribe al CRM real de Cumbre y consume el agente de IA real, que cuesta dinero por llamada. Si quieres probar un cambio, no tienes un lugar seguro para hacerlo: cada ejecución de prueba toca el CRM verdadero y gasta tokens verdaderos. Entonces pruebas poco, con miedo, y a veces no pruebas y rezas. Esta fragilidad la resuelven los entornos y el sandbox: el Módulo 4 (entornos dev/staging/prod aislados) y el Módulo 5 (prueba con datos sintéticos y credenciales de prueba a costo cero).

Fragilidad 3: cuando lo mueves, se rompe en silencio. Este es el más traicionero, y es el corazón de las lecciones 4 y 5 de este mismo módulo. Supón que exportas order-triage y lo importas en la instancia de un compañero, o en un servidor nuevo. El workflow parece llegar completo —ahí están todos los nodos—, pero el nodo AI Agent apunta a una credencial que en la nueva instancia no existe, y la llamada HTTP al CRM apunta a otra credencial que tampoco existe. No lanza un error grande y rojo al importar: se queda callado, y solo revienta cuando alguien lo ejecuta. Esta fragilidad la resuelve entender la anatomía del JSON (lección 4) y qué campos se rompen al reimportar (lección 5), y después manejarla con credenciales por entorno (Módulo 4).

Detente un segundo en esto, porque es la idea que sostiene toda la guía: las tres fragilidades son invisibles mientras todo esté en tu editor y nadie lo mueva. El constructor no las ve porque nunca sale de su editor. El dueño del sistema las ve porque su trabajo es, precisamente, sacar el workflow del editor —versionarlo, probarlo en otro entorno, entregarlo a otra persona— y ahí es donde las tres saltan. La guía completa es el conjunto de técnicas para que ninguna de las tres te agarre por sorpresa.

El reparto del mercado, con números

Ya vimos en la lección 1 los números de una muestra de unas 38 ofertas serias que mencionan n8n. Vale la pena volver sobre ellos con más detalle, porque cuentan una historia que a primera vista se lee al revés de como es.

Lo que pide la oferta	Cuántas de 38	Cómo leerlo
Prueba en sandbox o entornos separados (staging/prod)	~12	Casi una de cada tres exige poder probar sin tocar producción
Control de versiones con Git	~6	Una de cada seis lo pide con nombre y apellido
Documentación / handoff explícito	Aparece junto a las anteriores	Rara vez sola; acompaña a las que piden lo demás

La lectura ingenua es: "solo 6 de 38 piden Git, entonces el 84% del mercado no lo necesita, no vale la pena". Esa lectura es un error, por tres razones que conviene desarmar una por una.

Primera: estas señales viajan juntas y se concentran. Las ofertas que piden Git son casi siempre las mismas que piden entornos, y las mismas que piden documentación. No están repartidas al azar entre las 38: se agrupan en un subconjunto. Ese subconjunto no es "el 16% del mercado"; es "el segmento del mercado que trata la automatización como ingeniería en vez de como una tarea". Y ese segmento tiene una característica que lo hace desproporcionadamente importante para tu carrera.

Segunda: ese segmento es el que paga. Las ofertas que describen el entregable como "version-controlled, documented JSON" y hablan de "staging and production environments" son sistemáticamente las mejor remuneradas y las más remotas —es decir, las que pagan en monedas fuertes y no te atan a una ciudad—. No es casualidad. Una empresa que exige versionado y entornos es una empresa que ya entendió que la automatización es infraestructura crítica, y una empresa que entiende eso paga por gente que lo entienda también. El 84% que no lo pide incluye muchas vacantes junior, muchas agencias que subcontratan trabajo por pieza, y muchos puestos donde "automatizador" es media función de alguien que hace otras cinco cosas.

Tercera: la señal no es la proporción, es el vocabulario. Aunque solo 6 de 38 escriban "Git", muchas más describen la capacidad sin nombrar la herramienta: "ability to deploy changes safely", "experience maintaining automations in production", "must be able to roll back". Todas esas frases son la misma capacidad con otras palabras. Si contaras por capacidad en vez de por herramienta, el número sube bastante. Y todas apuntan al mismo lado de la línea: el dueño del sistema.

Dicho de otra forma: no persigues el 16%. Persigues el segmento del mercado que trata tu oficio con seriedad, que resulta ser el que mejor paga y el que te da más autonomía. Los números pequeños de la tabla son la puerta a los sueldos grandes.

Qué te descarta y qué te hace pasar

Bajemos esto a lo práctico. En una entrevista técnica para un rol de automatización serio, hay respuestas que te descartan casi automáticamente y respuestas que te hacen pasar. No es sobre memorizar guiones; es sobre entender qué está evaluando quien pregunta.

Lo que te descarta son las respuestas que revelan dependencia de tu memoria y tu cuidado personal, porque son las que la empresa no puede comprar:

• "Hago backups cada tanto" —te descarta porque "cada tanto" no es un sistema, y "backup" no es versionado: es una foto sin historia.
• "Tendría cuidado de no romper producción" —te descarta porque el cuidado no escala y no se puede auditar; la empresa necesita una barrera, no una promesa.
• "Comparo los archivos a ojo" —te descarta porque anuncia que no sabes leer un diff, que es una habilidad básica del rol (lección 3 del Módulo 2).
• "Está todo en mi n8n, te lo muestro" —te descarta porque confunde una demo con un entregable.

Lo que te hace pasar son las respuestas que describen mecanismos que funcionan sin ti:

• "El workflow vive versionado en Git; cada cambio queda con su motivo y puedo revertir a cualquier punto."
• "Desarrollo en dev, pruebo en staging, promuevo a prod; cada entorno tiene sus credenciales."
• "Pruebo con credenciales de prueba y datos sintéticos, así nunca toco los datos reales hasta producción."
• "Entrego un repositorio con el workflow y un README que explica por qué está armado así, para que otra persona lo pueda operar."

Fíjate en el patrón: las respuestas que te descartan hablan de lo que tú harías con cuidado; las que te hacen pasar hablan de lo que el sistema garantiza por diseño. El entrevistador no está evaluando si eres cuidadoso —todos dicen que lo son—. Está evaluando si construiste garantías que sobreviven a que tú tengas un mal día.

Hay un matiz que conviene no perder: esto no significa que tengas que responder con jerga. Un buen entrevistador desconfía de quien recita palabras de moda sin entenderlas. Lo que te hace pasar no es decir "CI/CD" o "rollback" como conjuros; es poder explicar, en lenguaje simple, el mecanismo que hay detrás. "Vuelvo a la versión anterior en un minuto porque cada cambio quedó guardado con su motivo" vale más que "tengo un pipeline de CI/CD", si a la segunda frase no le sigue una explicación de qué hace. La honestidad de decir "esto lo sé hacer, esto lo estoy aprendiendo" pesa más que la lista de palabras. El objetivo de esta guía no es que suenes a dueño del sistema; es que lo seas, y entonces sonar es automático.

Y hay un atajo honesto para todo esto, que es la tesis de esta guía: el artefacto habla por ti. Si en la entrevista puedes decir "aquí está el repositorio en GitHub, con el workflow versionado, documentado, con su configuración de entornos y su nota de riesgos", ya respondiste todas las preguntas de una sola vez. No tienes que convencer con palabras de que eres un dueño del sistema: lo demuestras con el entregable. Ese artefacto es, literalmente, el proyecto final de esta guía, y su primera piedra es el proyecto de este módulo (lección 8).

El artefacto de portafolio, en concreto

Terminemos de aterrizar qué es ese artefacto, porque es la meta de todo el camino y conviene tenerlo claro desde el módulo 1.

Al final de la guía vas a tener, en GitHub, un repositorio que contiene:

1. El workflow order-triage exportado como JSON, normalizado para que sus cambios se lean limpio (Módulo 3).
2. Un README de handoff que explica qué hace, cómo está armado y cómo operarlo, con las credenciales fuera del repositorio (Módulo 3).
3. Una configuración de entornos dev/staging/prod aislados con Docker Compose, cada uno con su propia clave de cifrado y sus credenciales (Módulo 4).
4. Una pasada de prueba en sandbox documentada, ejecutada a costo cero con datos sintéticos y credenciales de prueba (Módulo 5).
5. Un runbook de promoción y rollback y un chequeo automático que valida el JSON en cada cambio (Módulo 6).

Ese repositorio es defendible en una entrevista y funciona como prueba de que no solo construyes workflows, sino que los versionas, pruebas, promueves y operas. Es la receta escrita, no el taco. Es lo que te mueve de la primera taquera a la segunda.

Vale la pena imaginar qué ve la persona que evalúa cuando abre ese repositorio en GitHub, porque explica por qué el artefacto vale más que cualquier cosa que digas. Lo primero que encuentra es un README que, en dos minutos de lectura, le dice qué hace el sistema y cómo operarlo. Después ve la lista de cambios —los commits— y puede leer la historia de tus decisiones: "add manual review for orders over 5000", "switch CRM auth to per-environment credential", "pin test data for the AI Agent". Cada uno cuenta una decisión de ingeniería con su motivo. Ve que las credenciales no están en el repositorio, sino referenciadas y documentadas aparte —señal de que entiendes de seguridad—. Ve tres carpetas o archivos de configuración, uno por entorno, y entiende que sabes separar prueba de producción. Ve una nota de riesgos de portabilidad y sabe que anticipas lo que se rompe al mover un workflow.

Nada de eso lo tuviste que decir. El evaluador lo leyó. Y una cosa leída pesa más que una cosa afirmada, porque no se puede fingir: o el repositorio está ahí y está bien hecho, o no está. Por eso el artefacto es el mejor argumento de tu carrera. No pide que te crean; muestra.

Y hay un beneficio silencioso que a veces se pasa por alto: construir ese artefacto te obliga a aprender de verdad cada capacidad de dueño del sistema. No se puede tener un repositorio con entornos separados sin haber montado entornos separados. El proyecto no es una vitrina que decoras al final; es la forma en que interiorizas cada módulo. Cuando lo termines, no solo tendrás algo que mostrar: sabrás hacerlo, que es lo que la entrevista realmente comprueba.

No necesitas nada de eso todavía. Lo único que quiero que tengas claro al salir de esta lección es el destino: hacia allá vamos, y cada módulo pone una pieza. La pieza de este módulo, la más humilde y la más importante porque es la primera, es simplemente tomar un workflow, exportarlo y entender qué le pasaría si lo movieras de instancia. Con eso empieza todo.

Errores comunes

Confundir una demo con un entregable (conceptual). Qué pasa: alguien prepara para una entrevista una demo impecable —abre su n8n, ejecuta el workflow en vivo, todo funciona— y se sorprende cuando eso no alcanza. Por qué pasa: la demo es lo que uno controla y lo que se siente impresionante, así que uno invierte ahí toda la preparación. Pero la demo prueba que el workflow funciona hoy, contigo, en tu máquina, que es justo lo que el entrevistador ya daba por hecho. Cómo detectarlo: si tu plan para la entrevista es "se los muestro corriendo", tienes este problema. Cómo corregirlo: prepara el entregable, no la demo. Lleva el repositorio, no la pantalla. La pregunta que decide no es "¿funciona?", es "¿qué pasa cuando tú no estás?".

Leer los números del mercado al revés (conceptual). Qué pasa: alguien ve "solo 6 de 38 piden Git" y concluye que es una habilidad de nicho que no vale la pena aprender. Por qué pasa: es una lectura estadística ingenua que trata a las 38 ofertas como intercambiables. Cómo detectarlo: si tu razonamiento es "la mayoría no lo pide, entonces no importa", estás cometiendo el error. Cómo corregirlo: recuerda que las ofertas no son intercambiables. Las 6 que piden Git son sistemáticamente las que pagan más y dan más autonomía, y muchas más describen la misma capacidad sin nombrar la herramienta. No persigues una proporción; persigues un segmento, y ese segmento es el bueno.

Creer que "dueño del sistema" significa "mejor constructor" (conceptual). Qué pasa: alguien entiende que hay un rol más valorado y asume que el camino es construir workflows más complejos, más grandes, más impresionantes. Por qué pasa: es la progresión natural que uno espera —hacerse mejor en lo que ya hace—. Pero el eje de la mejora no es la complejidad del workflow, es la disciplina alrededor de él. Cómo detectarlo: si tu plan para "subir de nivel" es solo "construir cosas más difíciles", te falta el otro eje. Cómo corregirlo: el dueño del sistema no necesariamente construye workflows más complejos que el constructor; los envuelve en versionado, entornos, prueba y documentación. Un workflow simple, versionado y documentado, vale más en el mercado que uno complejo que solo existe en el editor de quien lo hizo.

Pensar que esto es solo para conseguir empleo (conceptual). Qué pasa: alguien que ya tiene trabajo, o que automatiza para su propio negocio, concluye que todo esto de entregables y entrevistas no le aplica. Por qué pasa: el marco de "el mercado pide" suena a búsqueda de empleo. Cómo detectarlo: si crees que versionar es solo para el portafolio, tienes esta creencia. Cómo corregirlo: el mismo entregable que te hace pasar una entrevista es el que te salva a las tres de la mañana cuando tu propia automatización se rompe. La empresa pide versionado porque protege a la empresa; a ti te protege igual, seas empleado o dueño. El artefacto no es para impresionar; es para dormir tranquilo.

Ejercicios

Ejercicio 1 — Clasifica cinco vacantes. Toma cinco ofertas reales de n8n (las mismas del ejercicio de la lección 1 sirven). Para cada una, decide de qué lado de la línea está: ¿describe un puesto de constructor (arma workflows, ejecuta configuraciones) o de dueño del sistema (versiona, opera, entrega)? Anota qué frase específica de la oferta te hizo decidir.

Ver solución

No hay una respuesta fija, pero sí un método. Las frases que delatan un puesto de constructor: "build automations", "create workflows", "connect tools", "no-code". Las que delatan un puesto de dueño del sistema: "version control", "Git", "staging/production", "deploy", "maintain in production", "documented", "roll back", "CI/CD", "handoff".

Un hallazgo típico: muchas vacantes son mixtas —piden construir y mantener— y ahí está el matiz interesante. Cuando una oferta pide las dos cosas, la parte de "mantener/versionar/desplegar" suele ser la que decide el sueldo y la que menos candidatos pueden demostrar. Es donde tienes ventaja si terminas esta guía.

Por qué funciona: la habilidad que estás practicando es leer una oferta por su capacidad requerida, no por su título. Un título que dice "n8n developer" puede esconder cualquiera de los dos puestos; los requisitos lo revelan. Esa lectura es lo que te permite postularte a lo que puedes ganar y no perder tiempo en lo que no.

Ejercicio 2 — Reescribe una respuesta de entrevista. Toma esta respuesta de constructor y reescríbela como la daría un dueño del sistema, usando los conceptos de esta guía (repositorio, entornos, credenciales de prueba, rollback). No inventes que ya sabes hacerlo; escríbela como el compromiso de lo que vas a poder responder al terminar la guía.

Pregunta: "¿Cómo manejas los cambios a un workflow que ya está en producción?" Respuesta de constructor: "Hago el cambio con cuidado y si algo sale mal lo arreglo rápido."

Ver solución

Una reescritura posible:

"No toco el workflow de producción directamente. El cambio lo hago en un entorno dev, con credenciales de prueba y datos sintéticos, así puedo ejecutarlo las veces que necesite sin efectos reales. Cuando funciona, lo pruebo en staging, que se parece a producción pero sigue usando credenciales de prueba. Recién cuando pasa esas pruebas lo promuevo a prod. Todo el proceso está versionado en Git, así que cada cambio queda registrado con su motivo y, si algo sale mal en producción, vuelvo a la versión anterior en un minuto porque quedó guardada."

Lo que cambió no es el tono, es el contenido: la respuesta de constructor describe una intención ("con cuidado"); la de dueño del sistema describe un mecanismo (entornos, versionado, rollback). La primera pide confianza; la segunda la genera.

Por qué funciona: en una entrevista, "con cuidado" es lo que dice todo el mundo, y por eso no dice nada. La respuesta que nombra un mecanismo concreto demuestra que el sistema no depende de tu buena voluntad. Nota que no necesitas todavía saber ejecutar esto —lo aprendes en los módulos siguientes—; necesitas entender la forma de la respuesta, y ya la entiendes.

Ejercicio 3 — Escribe tu inventario de partida. Haz una lista honesta de dos columnas. En la izquierda, lo que ya puedes hacer como constructor (arma workflows, conecta APIs, usa el nodo AI Agent, lo que sea). En la derecha, las capacidades de dueño del sistema que todavía no tienes (versionar con Git, entornos separados, prueba en sandbox, rollback, documentación de handoff). Guarda la lista.

Ver solución

No hay solución correcta: es tu inventario, no el mío. Pero hay una forma correcta de usarlo.

La columna izquierda es tu punto de partida y es más valiosa de lo que crees: esta guía no funciona sin ella. No se puede versionar y entregar lo que no se sabe construir. Si tu columna izquierda está vacía —si nunca armaste un workflow completo—, ese es el momento de volver a las guías de fundamentos antes de seguir aquí.

La columna derecha es el temario de esta guía, módulo por módulo. Versionar con Git es el Módulo 2; entornos es el Módulo 4; prueba en sandbox es el Módulo 5; rollback y handoff se reparten entre el 3 y el 6. Al terminar la guía, vuelve a esta lista y tacha lo que hayas movido de la derecha a la izquierda.

Por qué funciona: el ejercicio convierte una ansiedad difusa ("me falta un montón") en un mapa concreto ("me faltan estas cinco cosas, y cada una tiene su módulo"). La distancia entre constructor y dueño del sistema no es un abismo de talento; es una lista de capacidades aprendibles, y ahora la tienes escrita.

Resumen y siguiente paso

En esta lección viste que "funciona en mi editor" no es un entregable: es un talento personal, frágil y atado a una persona, como los tacos de la taquera que solo ella sabe hacer. El entregable que el mercado pide es otra cosa —version-controlled, documented JSON—, algo que una empresa puede recibir, operar sin ti, auditar y recuperar. Viste al mismo candidato en dos entrevistas, con el mismo talento para construir y respuestas de dos mundos distintos, y entendiste que el entrevistador no evalúa si sabes construir —lo da por hecho— sino si construiste garantías que funcionan sin ti. Volviste sobre los números del mercado —unas 12 de 38 ofertas pidiendo entornos, unas 6 pidiendo Git— y viste por qué esa proporción pequeña es la puerta a los sueldos grandes: esas señales viajan juntas, se concentran en el segmento que mejor paga, y muchas más ofertas describen la misma capacidad sin nombrar la herramienta. Y conociste el artefacto que resuelve la entrevista de un golpe: el repositorio versionado y documentado que es el proyecto final de esta guía.

Antes de avanzar deberías poder: explicar en una frase por qué una demo no es un entregable; nombrar dos respuestas de entrevista que te descartan y dos que te hacen pasar; y decir qué contiene el artefacto de portafolio hacia el que vamos.

Ya tienes claro el para qué y el para quién. Lo que sigue es empezar a desarmar el problema técnico. La lección 3 se mete en cómo se exporta hoy un workflow desde el editor de n8n 2.0 —los menús exactos, los formatos— y en por qué esa forma de guardar y compartir JSON, aunque es lo que casi todos hacen, no es control de versiones: no te da historial, ni revisión, ni rollback, ni una manera limpia de trabajar en equipo. Ahí empieza a verse, con detalle técnico, por qué el "funciona en mi editor" se queda corto.

Recursos

• Export and import workflows — n8n Docs — cómo n8n permite exportar un workflow como JSON; el punto de partida técnico de la lección 3.
• Source control and environments — n8n Docs — la sección oficial que describe las capacidades de versionado y entornos que definen el rol de "dueño del sistema"; nota que la integración nativa es de los planes de pago (lección 7).
• Tutorial: Create environments with source control — n8n Docs — el flujo dev/staging/prod con la feature nativa de pago; lo replicamos a costo cero en el Módulo 4.
• n8n community forum — donde aparecen las conversaciones reales de la comunidad, incluidas las quejas sobre control de versiones que motivan esta guía; útil para leer cómo la gente describe estos problemas con sus propias palabras.