Un proceso manual necesita código cuando se repite igual todos los días, cuando el error lo descubre el cliente antes que tú y cuando el volumen ya no cabe en el rato que alguien le puede dedicar. Con que se cumplan dos de las tres, la pregunta deja de ser si automatizar y pasa a ser con qué.

Porque hay tres niveles, no dos: hacerlo a mano, hacerlo con una herramienta no-code y escribir código. Saltar del primero al tercero suele ser caro de más. Quedarse en el segundo cuando el volumen ya no da también.

Las seis señales

No hace falta auditoría. Si marcas dos, el proceso ya pide máquina:

• Lo haces más de una vez al día y siempre igual. Copiar el pedido de la tienda a la hoja, avisar por WhatsApp, marcar la fila en verde. Cero decisiones de criterio, misma secuencia.
• Hay una hoja de cálculo intermedia. Un archivo que nadie diseñó y que alguien cuadra por las noches. Ese archivo es el síntoma más fiable: el proceso ya está automatizado a medias, solo que la máquina eres tú.
• Solo funciona si está esa persona. Si el proceso se cae cuando alguien se va de vacaciones, no es un proceso: es una costumbre.
• Los fallos los detecta el cliente. Te enteras de que el stock estaba mal porque te escriben, no porque salte una alerta.
• El tiempo escala igual que el volumen. Cien pedidos tardan diez veces lo que diez. Un proceso automatizado no funciona así.
• Hay una ventana de tiempo que se te escapa. El aviso que había que mandar a las 2 horas se manda al día siguiente porque nadie estaba mirando.

La cuenta que decide, en cinco minutos

Cronometra el proceso una vez. Supón, como ejemplo, 18 minutos al día, cinco días a la semana: son unas 6,5 horas al mes. Ponle el coste real de esa hora, no el salario mínimo. Súmale lo que cuesta un error: un pedido cancelado, un lead que se enfrió, un envío repetido.

Ese número es tu presupuesto anual disponible. Si sale por debajo del coste de una herramienta no-code bien configurada, sigue haciéndolo a mano y no te sientas mal. Si sale muy por encima, ya tienes la respuesta.

Cuándo el no-code deja de salir barato

Aquí está el detalle que casi nadie mira antes de firmar: cada plataforma te cobra por una unidad distinta, y eso decide el precio real de tu flujo mucho más que el precio de la etiqueta.

Las cifras salen de las páginas oficiales de Zapier, Make y n8n.

La diferencia se ve con un ejemplo. Un flujo de doce pasos que corre 1.000 veces al mes:

• En Make son 12.000 créditos, porque el centro de ayuda define la operación como «una ejecución de módulo»: mandar 5 emails son 5 operaciones.
• En Zapier, según su documentación de límites, un task es «cualquier acción con éxito». No cuentan los triggers, los filtros, los pasos de Paths, las acciones fallidas ni Formatter, Delay, Looping o Digest. Así que el número real está por debajo de 12.000, pero sigue creciendo con cada paso que añades.
• En n8n son 1.000 ejecuciones, porque el plan de 20 €/mes incluye «2.5K workflow executions with unlimited steps».

Esa asimetría es la señal económica. Mientras el flujo sea corto y poco frecuente, da igual la herramienta. Cuando el flujo se alarga y se repite, el modelo por paso te penaliza y el modelo por ejecución —o tu propio servidor— gana.

Ojo también con la concurrencia. La documentación de n8n avisa de que el control de concurrencia «se aplica solo a ejecuciones de producción: las iniciadas por un webhook o un nodo trigger», y que lo que excede el límite se encola y se procesa en orden FIFO. Si tu pico es a las 8 de la noche del viernes, ese encolado se nota.

La señal técnica: cuando chocas contra los límites de la API

Este es el punto en el que el no-code deja de ser una opción, no por precio, sino porque no llega.

Fuentes: Shopify.dev, Stripe Docs, Airtable Web API y Meta for Developers.

Airtable es el caso más didáctico: pasarte devuelve un 429 y obliga a esperar 30 segundos antes de que los reintentos vuelvan a funcionar. Un script sin control de tasa convierte eso en medio minuto de nada cada vez que hay prisa.

Y luego están los webhooks. Meta documenta que firma todos los avisos con SHA256 en la cabecera X-Hub-Signature-256, y que si tu servidor falla «reintentaremos de inmediato, y luego unas cuantas veces más con frecuencia decreciente durante las siguientes 36 horas» (Graph API Webhooks). Dos consecuencias prácticas: hay que verificar la firma, porque si no cualquiera puede llamar a tu endpoint, y hay que hacer el proceso idempotente, porque el mismo evento va a llegar varias veces y no puede generar dos pedidos ni dos mensajes.

Verificar firma, controlar reintentos, respetar límites de tasa y dejar registro. Eso es código. No es un capricho técnico: es la diferencia entre una automatización que aguanta el pico de campaña y una que duplica pedidos.

Lo que hay que tener escrito antes de tocar nada

Sea no-code o desarrollo propio, sin esto no se empieza:

1. Los pasos numerados, tal y como los hace hoy la persona. Sin mejorar nada todavía.
2. La clave única que identifica cada elemento: número de pedido, ID de conversación, SKU. Es lo que evita duplicados.
3. Qué pasa cuando falla. Reintentar, avisar, o parar y dejarlo en una cola.
4. Quién recibe la alerta y por dónde.
5. Dónde queda el registro de lo que se ejecutó, para poder revisar una semana después.

El lunes por la mañana

Tres cosas concretas, en este orden:

1. Elige un solo proceso, el que más te duele. Cronométralo esta semana con un temporizador de verdad, no a ojo. Apunta también cuántas veces salió mal.
2. Escribe los pasos numerados en un documento y marca cuáles requieren criterio humano. Si no hay ninguno, es candidato directo a automatizar.
3. Entra en la cuenta de la herramienta que ya uses y mira el consumo del mes: tasks en Zapier, créditos en Make, ejecuciones en n8n. Si vas al 80% a mitad de mes, la señal ya está delante de ti.

Con esas tres cosas sobre la mesa, la decisión entre seguir a mano, montarlo en no-code o escribir código deja de ser una opinión y pasa a ser una cuenta.

Preguntas frecuentes

¿Cuándo pasar de hacerlo a mano a automatizarlo?

Cuando el proceso se repite a diario con los mismos pasos y sin decisiones de criterio. Si además ya existe una hoja de cálculo intermedia que alguien cuadra por las noches, el proceso ya está automatizado a medias, solo que la máquina eres tú.

¿Zapier, Make o código propio?

Depende de la unidad de cobro. Zapier factura por acción con éxito, Make por ejecución de módulo y n8n por ejecución de workflow con pasos ilimitados. Un flujo de doce pasos que corre mil veces al mes son doce mil operaciones en Make y mil ejecuciones en n8n. Cuando esa diferencia se nota en la factura, compensa el desarrollo propio.

¿Qué hace el código que no hace el no-code?

Verificar la firma de los webhooks, controlar los reintentos para que un mismo aviso no se procese dos veces, respetar los límites de tasa de cada API y dejar registro de lo que pasó. Son las cuatro cosas que fallan cuando el volumen sube.

Fuentes

• Zapier Help — definición oficial de «task» y qué pasos no la consumen
• Zapier Pricing — planes y límite de tasks del plan gratuito
• Make Help Center — definición de operación y ejemplos de conteo
• Make Pricing — precio por créditos mensuales y unidad de cobro
• n8n Pricing — precio por ejecuciones de workflow con pasos ilimitados
• n8n Docs — control de concurrencia y cola FIFO en producción
• Meta for Developers — firma SHA256 de los webhooks y ventana de reintentos de 36 horas
• Meta for Developers — mensajes por segundo en Cloud API y en la app de WhatsApp Business
• Shopify.dev — puntos por segundo de la Admin API según el plan
• Stripe Docs — límite global de peticiones por segundo y asignación de lecturas
• Airtable Web API — 5 peticiones por segundo por base y respuesta 429