Qué separa un prototipo en Make de un sistema en producción
El escenario funciona. Lo montaste en una tarde, lo probaste con cinco registros y salieron los cinco. La sensación es de haber terminado, y es exactamente ahí donde empieza el problema: un prototipo demuestra que el proceso es posible; un sistema en producción demuestra que sigue siendo posible el martes a las tres de la mañana, con un dato raro y la API del otro lado caída. Entre esas dos cosas hay trabajo, y no es trabajo de arrastrar módulos.
Cuando hablamos de una automatización en Make que no escala, casi nunca falla la lógica de negocio. Falla por cuatro cosas que el prototipo no tenía porque no le hacían falta: un techo de ejecución que solo aparece con volumen, un comportamiento ante errores que hay que decidir a mano, la ausencia total de versionado y una factura que crece justo cuando haces las cosas bien.
| Dimensión | Prototipo que funciona | Sistema en producción |
|---|---|---|
| Volumen | Cinco registros de prueba | El pico de fin de mes, sin avisar |
| Errores | No hubo ninguno | Se da por hecho que los habrá y se decide qué pasa con el dato |
| Dueño | Quien lo montó, si se acuerda | Alguien de guardia, con alerta y procedimiento |
| Cambios | Se edita en caliente | Se versiona, se prueba aparte y se promociona |
| Coste | Cabe de sobra en el plan | Se proyecta a doce meses con los pasos endurecidos |
Ninguna de esas cinco filas es un defecto de Make. Make es una herramienta excelente para descubrir si un proceso se puede automatizar, y esa fase importa. El error no es empezar ahí: es quedarse ahí y llamarlo producción.
El techo de tiempo: 40 minutos y lo que pasa cuando lo tocas
Make corta cualquier ejecución que supere su tiempo máximo. En los planes de pago ese techo son 40 minutos; en el plan gratuito, 10. Cuando lo tocas no recibes un aviso amable: la corrida se detiene con un error de tipo «MAXIMUM EXECUTION TIMEOUT [40 minutes] had elapsed» y lo que quedaba a medias se queda a medias.
Un prototipo nunca lo toca. Procesa cinco filas y termina en doce segundos. El patrón que lo revienta es siempre el mismo y siempre por sorpresa: un iterador sobre una lista que crece. Sincronizas 200 pedidos y va bien; a los seis meses son 4.000 y el escenario se muere a mitad de camino, después de haber consumido las operaciones de los 2.700 primeros. El proceso no ha cambiado. Ha cambiado el negocio, que era el objetivo.
La salida correcta casi nunca es subir de plan, porque el techo de tiempo no se compra: se rediseña. El patrón que funciona es partir el trabajo en dos escenarios —uno que recoge y encola, otro que consume la cola por lotes pequeños con su propia programación— de modo que ninguna corrida individual se acerque al límite. Es más trabajo que arrastrar un módulo más, y es la diferencia entre un flujo que aguanta el crecimiento y uno que se rompe justo cuando el negocio va bien.
Qué hace Make cuando algo falla (y qué no hace por ti)
Make trae una red de seguridad que mucha gente ni activa: las ejecuciones incompletas. Cuando un escenario revienta a mitad, en lugar de perder el dato la plataforma guarda la corrida inacabada para que puedas reanudarla o repararla. Es una buena red y conviene usarla. También tiene bordes, y los bordes son la letra pequeña que decide si tu sistema pierde información.
El almacén de incompletas no es infinito: hay un límite por escenario sin resolver —del orden de 10 MB— y un tope agregado por equipo —del orden de 500 MB—, y las que resuelves se borran automáticamente a los 30 días. La parte incómoda llega cuando ese almacén se llena, porque entonces el comportamiento depende de una casilla de configuración que alguien marcó hace meses sin pensarlo: si la pérdida de datos está desactivada, Make desactiva el escenario; si está activada, Make sigue lanzando corridas y descarta la ejecución incompleta que no cabe. Ninguna de las dos opciones es buena. Una te para el negocio, la otra te lo vacía en silencio.
| Qué falla | Qué hace Make por defecto | Qué tienes que decidir tú |
|---|---|---|
| 429 de la API destino (rate limit) | La ejecución muere; si tienes activadas las ejecuciones incompletas, el dato se guarda ahí | Cuántos reintentos, con cuánta espera y qué pasa cuando se agotan |
| 503 transitorio del otro lado | Lo mismo: se corta donde estaba | Si reintentas o si el registro se va a una cola de revisión humana |
| Dato inesperado (campo vacío, formato raro) | Nada especial: revienta el módulo que lo toque | Validar antes de entrar y mandar el caso raro a una persona |
| Almacén de incompletas lleno | Desactiva el escenario, o descarta la ejecución, según una casilla | Cuál de los dos males prefieres — y cómo te enteras de que ha pasado |
Hay un segundo error clásico, y es autoinfligido: el reintento sin tope. Un manejador de errores que reintenta indefinidamente contra una API que está devolviendo 429 no arregla nada; quema operaciones a ritmo de incendio y bloquea el escenario. Todo reintento necesita tres cosas —un número máximo, una espera creciente entre intentos y un destino final para el registro cuando se agotan— y ese destino final normalmente es una persona. Cómo diseñar ese punto de salida sin convertirlo en un cuello de botella es exactamente el problema del humano en el bucle.
Versionado: el escenario que nadie sabe quién tocó
Make no trae control de versiones al estilo de un repositorio de código. La práctica extendida, y la que recomienda casi todo el mundo, es clonar el escenario antes de tocarlo y probar sobre datos de desarrollo. Funciona mientras seas uno. En cuanto sois tres, la carpeta se llena de copias con nombres como «Pedidos v2 FINAL (bueno)» y nadie sabe cuál está viva.
El coste real de no versionar no es el desorden, es que pierdes la capacidad de responder a tres preguntas el día que algo se rompe: qué cambió, quién lo cambió y cómo se vuelve atrás. Sin esas tres respuestas, cada incidente se convierte en arqueología. Y la arqueología, en producción, se paga en horas de gente cara mientras el proceso está parado.
- Un blueprint exportado por cada cambio. Make deja exportar el escenario como JSON: mételo en el repositorio de la empresa. Ahí tienes el diff que la plataforma no te da.
- Nomenclatura aburrida y estricta. Un nombre por escenario, un sufijo para la copia de trabajo, cero adjetivos. «FINAL» no es un estado.
- Un entorno de pruebas de verdad, con sus propias credenciales y datos falsos. Probar en producción con un registro real es exactamente lo que parece.
- Una persona que promociona. Cualquiera puede proponer un cambio; una sola persona lo pasa a producción. No es burocracia: es saber a quién preguntar a las tres de la mañana.
- Un registro de cambios de dos líneas. Fecha, qué se tocó, por qué. Nadie lo lee hasta el día que lo necesitas, y ese día vale por todos los anteriores.
Esto no es una manía de ingeniero: es la parte mínima de gobernanza y control de la automatización sin la cual no se puede decir que un proceso esté en producción. Un flujo que mueve dinero o datos de clientes y que cualquiera puede editar en caliente sin dejar rastro no es un sistema: es un riesgo con interfaz bonita.
La factura sube justo cuando lo haces bien
Aquí está la trampa que hace que mucha gente deje el escenario frágil a propósito, aunque no lo diga en voz alta. Make cobra por operación: cada módulo que procesa datos pasa por caja. Y todo lo que acabamos de describir —validar el dato de entrada, controlar errores, reintentar con espera, registrar lo que pasó, avisar a un humano cuando el caso es ambiguo— son módulos. Endurecer el flujo multiplica el consumo del mismo proceso sin automatizar ni un caso nuevo.
El resultado es un incentivo perverso perfectamente medible: la plataforma te cobra más por hacer el sistema más robusto. No es una maldad de Make, es la consecuencia matemática de cobrar por paso, y le pasa igual a cualquier herramienta con ese modelo. La comparación completa de las tres unidades de facturación —paso, operación y ejecución— está en el precio de las herramientas de automatización, y es la lectura que convierte esta guía en una decisión con números.
La consecuencia práctica: cuando proyectes el coste de llevar el prototipo a producción, no proyectes el escenario de hoy. Proyecta el escenario endurecido, que tendrá el triple de módulos, al volumen que esperas dentro de doce meses. Si esa cuenta sale mal, el problema ya no es de configuración; es de herramienta, y toca la conversación de Make frente a n8n.
Tres salidas: endurecer, partir o mover el motor
No todos los escenarios que se atascan necesitan lo mismo, y confundir el diagnóstico es caro en las dos direcciones: migrar por gusto cuesta semanas, y quedarse por inercia cuesta caídas. Estas son las tres salidas reales y la señal que las distingue.
| Tu situación | Qué hacer | Señal de que es tu caso |
|---|---|---|
| El escenario es correcto pero frágil | Endurecerlo donde está: validación, manejo de errores, alertas, logs | Falla poco, pero cuando falla nadie se entera hasta que lo pregunta un cliente |
| El escenario se ahoga por tamaño | Partirlo: uno que encola, otro que consume por lotes | Tocas el techo de tiempo, o el iterador crece cada mes |
| El modelo de precio te está castigando | Mover el motor a una herramienta que cobre por ejecución | La factura sube y no has añadido ni un proceso nuevo |
Las tres exigen la misma decisión previa, y es de organización, no de tecnología: alguien tiene que ser dueño del flujo. Un proceso automatizado sin dueño se degrada solo, porque las APIs cambian, los formatos se mueven y los casos raros aumentan con el volumen. Esa disciplina —quién mira qué, cada cuánto y con qué alertas— es la que describe el mantenimiento de las automatizaciones, y es la diferencia entre un sistema que envejece bien y uno que un día simplemente dejó de correr sin que nadie lo notara.