n8n vs. Automazione AI CustomUn framework decisionale che regge in produzione

"Dobbiamo usare n8n o costruire custom?" raramente è la domanda giusta. La domanda vera è: quali parti di questo problema si adattano a un workflow builder visuale e quali hanno bisogno di codice? La maggior parte dei sistemi in produzione usa entrambi e il trucco è sapere dove tracciare la linea.

Questo post espone i criteri che usiamo quando definiamo progetti di sviluppo software AI e automazione con i clienti. L'obiettivo non è venderti uno strumento. L'obiettivo è spendere il tuo budget dove guadagna davvero.

n8n è eccellente quando il workflow ha queste proprietà:

• Percorso principale deterministico. La maggior parte degli step è "chiama questa API, trasforma questo JSON, scrivi in questo foglio." Lo step AI è un condimento opzionale sopra.
• Volume basso-medio. Da qualche centinaio a qualche migliaio di run al giorno è il sweet spot di n8n. La versione self-hosted scala oltre con cura.
• Stato a vita breve. Ogni run è in larga parte autonoma; nessuna conversazione lunga o job di ore.
• Owner non ingegneri. Chi mantiene il workflow è ops, RevOps o marketing — non sviluppatori. Un builder visuale che possono leggere e modificare vale molto.
• Iterazione rapida. Devi spedire, misurare e modificare ogni settimana. n8n collassa il costo per cambio.

Un ottimo esempio: "quando un lead compila il form, arricchisci via Clearbit, classifica l'intent con un LLM, instrada al canale Slack giusto e crea un deal nel CRM." È territorio di n8n. Costruirlo in codice custom è sovradimensionato — e più difficile da passare a un non-ingegnere.

Il codice custom vince quando il workflow ha almeno uno di questi:

• Stato non banale. Conversazioni lunghe, agenti multi-step, job che durano minuti o ore e servono checkpoint — i builder visuali soffrono qui. Il codice lo esprime naturalmente.
• Branching complesso. Se il grafo ha più di ~15 nodi e loop multipli, n8n inizia a combattere con te. Il codice è più leggibile oltre quella soglia.
• SLA di affidabilità stringenti. Retry con exponential backoff, chiavi di idempotenza, lock distribuiti, degradazione graduale — tutto fattibile in n8n ma più economico in codice.
• Contratti tipizzati con il resto del prodotto. Se il workflow è davvero parte del prodotto con cui gli utenti interagiscono (non uno strumento ops), vuoi la stessa tipizzazione, testing e disciplina di deploy che applichi all'app.
• Logica AI-first. Workflow agentici con selezione dinamica di tool, retrieval e RAG sui documenti aziendali sono più puliti in codice. Puoi ancora chiamarli da n8n, ma il core AI vuole vivere in una codebase.
• Compliance e data residency. Se il workflow tocca dati regolamentati, spesso serve il pieno controllo di dove gira ogni step e cosa logga. Il codice custom te lo dà senza negoziare con una piattaforma.

n8n sembra più economico perché il primo workflow parte in giorni. La trappola è cosa succede dopo:

• Il workflow 2 impiega quasi quanto il workflow 1, perché non puoi condividere codice.
• Il workflow 10 è un labirinto di "sub-workflow" che nessuno ricorda.
• Ogni upgrade di provider rischia di rompere più flussi.
• L'osservabilità è per-nodo, non per-prodotto — difficile costruire una vista coerente.

Il codice custom ha il profilo opposto. Il workflow 1 è costoso perché stai pagando per costruire le fondamenta (deploy, logging, retry, eval). I workflow 2, 3, 4 partono in una frazione del tempo perché riusano quelle fondamenta. Al workflow 10, il costo per nuovo workflow è più basso che in n8n.

Regola empirica: sotto i ~3 workflow seri, scegli il builder visuale. Sopra, investi in una codebase.

Quasi ogni sistema in produzione che spediamo mescola entrambi. Una forma tipica:

• n8n per i bordi. Integrazioni di terze parti, ricezione webhook, trigger schedulati, glue a livello ops. Tutto ciò che il team ops deve possedere e cambiare senza l'engineering.
• Servizi custom per il core. La logica AI — prompt, retrieval, uso di tool, valutazione — vive in un piccolo servizio Python o TypeScript con test, osservabilità e CI/CD adeguati.
• Giunzione pulita. n8n chiama il servizio custom via HTTP con un payload tipizzato. Il servizio custom non richiama mai n8n; restituisce una risposta o scrive in una coda/DB condivisi.

Questa separazione rispetta chi possiede cosa. Il team ops può aggiustare le integrazioni senza rompere il core AI. Il team engineering può iterare su modelli e prompt senza rompere l'ops. I bug hanno case ovvie.

Si applica lo stesso framework. Zapier è più pesante sulle integrazioni SaaS e più leggero sul controllo self-hosted. Make è il builder visuale più espressivo ma non il più rapido per il passaggio a uno sviluppatore. Nessuno di loro cambia la domanda di fondo: il workflow è abbastanza semplice perché uno strumento visuale vinca?

Probabilmente devi spostare il core AI in codice custom se:

• Hai diviso un workflow in tre "sub-workflow" per farlo stare nella UI e ancora non vedi cosa fa.
• Il debug significa aprire l'output di 20 nodi uno alla volta.
• Hai scritto JavaScript in più della metà dei nodi.
• La gestione incidenti richiede spesso di ri-eseguire un workflow a metà perché lo step AI è cambiato.
• Hai la stessa logica di retrieval duplicata in quattro flussi.

Due dei precedenti e siamo lì. Non devi riscrivere tutto — solleva il core AI in un servizio e tieni n8n come superficie ops.

Se sei all'inizio e lo scope è piccolo, spedisci su n8n o simili. Misura i volumi reali, i failure mode reali e il carico di manutenzione reale. Tieni una lista dei workflow costruiti e una nota sul dolore di ognuno.

Quando il dolore su un workflow (o sull'insieme) supera la soglia, definisci il servizio custom. Di solito:

1. Facciamo audit dei workflow n8n o Zapier esistenti e li classifichiamo: restare, migrare, dismettere.
2. Progettiamo il core custom — tipicamente un piccolo servizio, un vector database e l'eval.
3. Migriamo uno o due workflow più ad alto valore per primi, mantenendo n8n come layer chiamante.
4. Ricostruiamo il resto solo quando il pattern è provato.

n8n e automazione AI custom non sono rivali — sono uno spettro, e la risposta giusta per il tuo business è quasi sempre "entrambi, con una giunzione chiara."

Se vuoi aiuto a mappare la tua automazione attuale e decidere quali parti meritano codice custom, il nostro sviluppo software AI copre esattamente questo tipo di lavoro. Leggi sui workflow AI agentici per più contesto, oppure contattaci con una descrizione del workflow che vuoi migliorare.