Cuándo tu flujo debería ser software, no siete herramientas

Un flujo debería convertirse en software cuando el costo de poseer la cadena — no de ejecutarla — supera el costo de poseer un programa pequeño. Ejecutar es barato en ambos casos: una cadena de herramientas corre en milisegundos y un script también, y ninguno aparece en la factura de un cliente. Poseer es donde los dos caminos se separan, y cuatro señales se mueven primero: cuántas veces el payload pasa de un sistema a otro, con qué frecuencia una ejecución necesita a una persona, cuánto tarda la respuesta a "¿el cliente realmente fue notificado?" y a quién suena el teléfono cuando esto se rompe a las 5pm. Si hoy no puedes responder esas cuatro preguntas en cinco minutos, no tienes un problema de automatización — tienes una que se convirtió en software silencioso que nadie documentó.

Construimos el mismo flujo dos veces

Así que lo hicimos. Un flujo, siete pasos: llega un lead, se valida, se deduplica, se enriquece, se califica, se escribe en el CRM, se notifica a ventas y se registra. Lo construimos de dos formas.

La primera versión es una cadena de siete servicios independientes. Cada uno tiene su propio archivo de configuración, su propia credencial, su propio registro, y le pasa JSON al siguiente por HTTP. Esa es la forma que tiene cualquier cadena entre proveedores: una herramienta de formularios, una API de enriquecimiento, un CRM, una pasarela de mensajería — lo que sean los logos en tu diagrama de stack.

La segunda versión es un solo script: un archivo de configuración, un registro, un almacén de credenciales, cero saltos entre sistemas. Mismas entradas, mismas salidas, la misma falla inyectada en el mismo lugar.

Una nota de honestidad antes de los números: esto es un modelo de cadena, no un benchmark de una plataforma específica. Un escenario de Make mantiene sus pasos en un solo historial de ejecución, y eso ayuda de verdad — hasta que el flujo cruza cuatro proveedores, momento en el que el historial se fragmenta por líneas de proveedor de todas formas. "Siete herramientas" significa siete inicios de sesión, y siete inicios de sesión no comparten un registro.

Lo que la cadena cuesta antes de que algo se rompa

Ninguno de esos números aparece en una factura. Aparecen como tiempo de onboarding, como el día de la rotación, como la frase "pregúntale a Diego, él lo construyó" — y Diego se fue en marzo.

La primera cifra que la gente pregunta es la velocidad: en 100 ejecuciones, la mediana de la cadena fue 20.5ms frente a 0.7ms del script. También es la que menos importa. Ningún cliente puede distinguir 20 milisegundos de 0.7. La medimos solo para mostrar que la cadena no compra nada en tiempo de ejecución — toda la diferencia vive en la propiedad.

Esta es la otra cara de la factura que ya documentamos desde el otro lado: el costo de integración que suma de 40% a 70% a un stack desconectado, y la trampa del costo por tarea que aparece como factura. Esos son los costos visibles. La tabla de arriba es el invisible.

Cuando se rompió, la cadena culpó a la herramienta equivocada

Cortamos el paso del CRM a mitad de ejecución y observamos qué le decía cada versión a quien la llamó.

El script devolvió 500 service_unavailable y nombró a crm — el paso que realmente falló. Un archivo de registro, una línea, la respuesta.

La cadena devolvió 502 y nombró a validate — el primer paso de la cadena, que no había hecho nada mal. El error real estaba a cuatro saltos de distancia, en el registro de otro servicio. Encontrarlo significó abrir los cinco archivos de registro que registraban esa ejecución y buscar el que no decía "ok".

Eso no es un accidente de nuestro arnés; es lo que hacen los saltos. Cada sistema que recibe una falla desde aguas abajo la reporta como su propia falla hacia aguas arriba, así que cuando el error llega a la persona que lo disparó, nombra el borde que tocaste y no el paso que se rompió. En una cadena, el mensaje de error describe dónde estabas parado, no qué se rompió.

En justicia: el script tampoco escapó de la escritura parcial. Ambas versiones dejaron el marcador de deduplicación escrito y ningún registro en el CRM — ninguna es transaccional por defecto, y pretender lo contrario es cómo los equipos eligen la herramienta equivocada. La diferencia no es qué se rompió. Es cuánto tarda enterarse: un registro que nombra el paso correcto, o cinco registros y un error que nombra al equivocado.

Un cambio, tres lugares que recordar

Pedimos un cambio pequeño: guardar el número de teléfono en el registro del CRM e incluirlo en la notificación a ventas.

La cadena necesitó tocar tres archivos de configuración — la lista permitida del validador, el mapa de campos del CRM, la carga del notificador — más reiniciar tres servicios. El script necesitó dos archivos y ningún reinicio. Ambos quedaron verificados después, con el teléfono llegando a la notificación en cada uno.

Luego lo rompimos a propósito: actualizamos el CRM y el notificador y dejamos sin tocar la lista permitida del validador. Ambas versiones aceptaron el cambio, devolvieron 200 y escribieron phone: null en el registro y en la notificación. Silencioso, idéntico, sin error en ningún lado.

Esa simetría es la parte honesta — un cambio parcial manda a cualquiera, y cualquier artículo que afirme lo contrario está vendiendo algo. Lo que cambia es la distancia entre las dos configuraciones que deben coincidir. En la cadena, la lista permitida y el mapa de campos viven en archivos distintos con dueños distintos: puedes actualizar uno y nunca abrir el otro. En el script, están a tres líneas en el mismo archivo. El error es del mismo tamaño. La probabilidad de cometerlo, no.

Cuando la cadena sigue siendo la respuesta correcta

La cadena gana, y no por poco, en estas situaciones:

• Personas distintas poseen pasos distintos. Quien edita el notificador no debería poder tocar la lógica del CRM. Las configuraciones separadas son un modelo de permisos.
• El flujo todavía cambia de forma. ¿Herramienta nueva cada trimestre? Reescribir software cada vez es un peor intercambio que poseer la cadena.
• El volumen es bajo y nadie nunca preguntará qué pasó con la ejecución #4,821. El tiempo de reconciliación deja de ser un problema por debajo de cierto volumen.
• Nadie poseerá un programa dentro de seis meses. El software sin dueño se pudre más rápido que una cadena sin dueño, porque al menos el proveedor de la cadena mantiene su mitad.

La cadena es un préstamo: cambias costo de propiedad por velocidad de cambio. El préstamo está bien hasta que el flujo deja de cambiar y empieza a ser algo de lo que la gente depende — que es el momento en que la mayoría de los equipos se da cuenta, usualmente durante una incidencia.

Las cuatro señales, en el orden en que fallan

Mídelas en ese orden. El conteo de saltos toma una tarde y predice las otras tres. La propiedad falla al final y cuesta más, porque para entonces el flujo es estructura y la persona que lo entendía ya no responde el correo.

Nuestra postura

Mantén la cadena mientras el flujo todavía está cambiando de forma. Conviértelo en software la primera vez que te atrapés explicando el flujo de memoria en lugar de leerlo — ese es el momento en que la cadena se volvió software sin documentar, y lo único que la mantiene viva es que nadie se ha ido todavía.

Empieza por la medición, no por la reescritura: mapea los saltos, cronometra un diagnóstico, nombra un dueño por paso. Si los cuatro números salen benignos, conserva la cadena y deja de preocuparte — nuestro trabajo de automatización y chatbots empieza exactamente por esa auditoría, y solo después tiene sentido la conversación cadena vs build. ¿Sigues eligiendo la plataforma? Make vs n8n vs Zapier es la comparación que está debajo de esta, y automatización con IA vs app a medida vs SaaS es la decisión más amplia que contiene a esta.