n8n, Make ou código à medida: como escolher a stack de automação

Quase todas as semanas ouvimos a mesma pergunta: “devíamos usar n8n, Make, Zapier ou contratar alguém para programar isto?” A pergunta esconde um erro comum: escolher a ferramenta antes de perceber o problema — e antes de pensar em quem vai manter aquilo a funcionar daqui a um ano.

Usamos as três abordagens em produção. Eis como decidimos, e porquê.

O critério: custo total de operação

Uma automação não é um projeto — é um sistema que fica a correr. O custo real inclui construção, licenças, e sobretudo manutenção: quem percebe o fluxo, quem o altera quando o processo muda, quem acorda quando ele parte às 3 da manhã. A ferramenta certa minimiza este total, não o tempo de construção.

Quando escolhemos Make ou Zapier

Fluxos simples, lineares, entre ferramentas conhecidas. Formulário → CRM → email de boas-vindas. Fatura recebida → pasta no Drive → notificação no Slack.

• A favor: arranque em horas; centenas de integrações prontas; a equipa consegue ver e ajustar sem programador.
• Contra: o preço cresce com o volume de operações; lógica complexa torna-se um espaguete de módulos; debugging limitado.

Regra prática: se o fluxo tem menos de dez passos e não tem ramificações complicadas, Make/Zapier é provavelmente a resposta mais barata — mesmo pagando a subscrição.

Quando escolhemos n8n

O nosso ponto de equilíbrio preferido para PMEs. O n8n é open-source, pode correr em servidor próprio ou na cloud deles, e aguenta lógica a sério: ramificações, loops, tratamento de erros, código JavaScript embutido quando é preciso.

• A favor: custo previsível (self-hosted não paga por operação); fluxos visuais que a equipa consegue ler; nós de IA nativos para chamar Claude, GPT e afins; sem lock-in.
• Contra: exige alguém que o administre (atualizações, backups); a curva de aprendizagem é maior que a do Make.

Regra prática: volume médio-alto, lógica com ramificações, dados sensíveis que não devem passar por terceiros, ou orçamento que não aguenta preços por operação — n8n.

Quando escolhemos código à medida

Quando a automação é o produto, ou quando falhar custa caro. Integrações com sistemas sem conectores, volume alto com requisitos de latência, lógica de negócio complexa, ou fluxos que precisam de testes automatizados e versionamento a sério.

• A favor: controlo total; testável, versionável, auditável; desempenho e custo marginais imbatíveis em escala.
• Contra: mais caro de construir; exige um programador para qualquer alteração.

Regra prática: se o fluxo é crítico para o negócio, muda pouco mas não pode falhar, ou faz parte de um produto — código, com CI e monitorização.

A resposta que damos na prática

A maioria dos nossos clientes acaba com uma combinação: n8n como espinha dorsal da automação interna, código para as peças críticas ou de alto volume, e ocasionalmente Make para fluxos periféricos que a equipa quer gerir sozinha.

O que nunca recomendamos: escolher a ferramenta primeiro e procurar problemas para ela depois. Descreva o processo, o volume, o custo de uma falha e quem vai manter o sistema — a escolha da stack quase se faz sozinha.