No-code vs. low-code: qual escolher para a sua equipa

A escolha entre no-code e low-code costuma ser apresentada como uma questão de competências: se tem programadores, escolha low-code; se não tem, no-code. É uma simplificação que leva muitas PME a decidir mal.

A pergunta útil é outra. Não é quanto código a plataforma exige hoje. É o que acontece no dia em que ela deixar de fazer aquilo de que precisa — e quem, na sua equipa, vai estar lá para resolver.

A diferença real não é o código. É o teto.

Uma plataforma no-code é fechada por desenho. Faz muito bem aquilo que os criadores previram, e não faz mais nada. Um formulário, uma aprovação, uma notificação, uma linha acrescentada a uma folha de cálculo: está tudo resolvido sem escrever um caractere.

Uma plataforma low-code faz o mesmo, mas deixa uma porta aberta. Quando o bloco visual não chega, escreve-se código naquele passo específico e o resto do fluxo continua igual.

Essa porta é o argumento central do low-code. Vale a pena perceber quão larga é na prática, porque é aí que a promessa costuma encolher.

No n8n, a porta chama-se nó Code e aceita JavaScript ou Python. Os limites, segundo a documentação oficial do nó Code, são concretos:

Na versão cloud não é possível importar módulos npm externos. Ficam disponíveis apenas o módulo crypto do Node.js e o pacote moment.
Ainda na cloud, a opção Python não permite importar biblioteca nenhuma — nem sequer as da biblioteca padrão.
O nó Code não acede ao sistema de ficheiros nem faz pedidos HTTP. Para isso existem nós próprios.
Em servidor próprio, a restrição aos módulos externos levanta-se.

A conclusão não é que o n8n seja limitado — é dos mais abertos do mercado. É que o teto existe sempre. No no-code está mais baixo e vê-se logo no primeiro dia. No low-code está mais alto e descobre-se tarde, já com o processo em produção e a equipa dependente dele.

Quem é que mantém isto daqui a dois anos?

Antes de assumir que "depois arranja-se alguém", vale a pena olhar para os números.

Segundo o Eurostat, em 2023 apenas 9,55% das empresas da UE recrutaram ou tentaram recrutar especialistas de TI — e 57,5% dessas tiveram dificuldade em preencher as vagas. Entre as pequenas empresas, a percentagem das que sequer tentaram foi de 6,23%, contra 51,87% nas grandes.

Lido ao contrário: a esmagadora maioria das PME não está no mercado de contratação de perfis técnicos, e as que estão têm mais de metade de probabilidade de não conseguir. Desenhar uma automatização a contar com um programador que ainda não existe é uma aposta com odds conhecidas.

Daqui não decorre, porém, que o no-code seja automaticamente a opção mais segura. Um fluxo no-code que só uma pessoa da empresa percebe tem exactamente o mesmo problema de um fluxo com código que só uma pessoa percebe. A diferença entre os dois não é a fragilidade — é o esforço para a corrigir.

Documentar os passos, dar-lhes nomes legíveis e garantir que uma segunda pessoa sabe abrir a ferramenta resolve mais do que a escolha de categoria alguma vez resolverá.

O modelo de preço diz mais do que a lista de funcionalidades

Comparar funcionalidades em páginas de fornecedor rende pouco: estão todas escritas para ganhar a comparação. O modelo de preço é mais informativo, porque revela o que cada plataforma considera caro.

Três modelos, com valores das páginas oficiais consultadas em agosto de 2026:

Zapier cobra por tarefa. Uma tarefa é cada passo concluído com sucesso. O plano gratuito dá 100 tarefas por mês e limita os fluxos a dois passos; o Professional começa em 19,99 dólares por mês, em faturação anual.
Power Automate cobra por pessoa. Segundo a página de preços da Microsoft, o plano Premium custa 15 dólares por utilizador e por mês, em faturação anual. A automação não assistida é à parte: 150 dólares por bot e por mês, ou 215 se o bot correr numa máquina gerida pela Microsoft.
n8n cobra por execução. Uma execução é uma corrida completa do fluxo, tenha ele 3 passos ou 40. O plano Starter são 20 euros por mês, com 2500 execuções incluídas.

Um caso com os números à vista

Imagine um fluxo de aprovação de despesas com cinco passos: recebe o pedido, valida o valor, consulta o responsável, regista no ERP, notifica quem pediu. Corre 500 vezes por mês e envolve cinco pessoas.

Ao preço por tarefa, 500 corridas com quatro passos faturáveis dão cerca de 2000 tarefas por mês. O escalão gratuito não chega perto e é preciso um plano pago com folga.
Ao preço por utilizador, são 5 × 15 dólares, ou seja 75 dólares por mês — 900 por ano. E esse valor sobe se amanhã forem doze pessoas, mesmo que o fluxo não mude uma vírgula.
Ao preço por execução, são 500 execuções contra um pacote de 2500. Cabe no plano de 20 euros por mês, e os cinco passos não custam mais do que dois custariam.

Este cálculo é ilustrativo, não é um orçamento. Parte de pressupostos simplificados sobre licenciamento, não inclui descontos nem impostos e ignora os passos que cada plataforma não fatura. Serve para mostrar a mecânica, que é o que interessa reter: o preço por tarefa penaliza fluxos complexos, o preço por utilizador penaliza equipas que crescem, o preço por execução penaliza volume alto.

Nenhum dos modelos é melhor. O que existe é correspondência, ou falta dela, entre o modelo de preço e a forma do seu processo. É por isso que compensa medir o processo antes de escolher a ferramenta: sem saber quantas vezes por mês aquilo corre e quantos passos tem, comparar preços é adivinhar.

Quando o no-code é a escolha certa

Há casos em que a discussão nem se justifica. O no-code ganha quando:

O processo é estável. Já corre há anos da mesma maneira e ninguém prevê mudá-lo tão cedo.
Não há perfil técnico na equipa nem intenção de contratar. Uma ferramenta que exige código e não tem quem o escreva é uma dependência externa disfarçada de autonomia.
O que se está a substituir é trabalho manual puro. Copiar de um sítio para o outro, reencaminhar emails, preencher a mesma folha todas as segundas-feiras.
O custo de errar é baixo. Se o fluxo falhar, alguém repara e refaz à mão sem consequências de maior.

O padrão repete-se: processo conhecido, requisitos que não vão fugir muito e uma equipa que precisa de autonomia para mexer sem pedir ajuda a ninguém.

Quando o low-code compensa o esforço

O low-code justifica-se quando aparece pelo menos um destes sinais:

Integração com sistemas sem conector pronto. ERPs nacionais, software de nicho e aplicações internas costumam ter API, mas raramente aparecem nas listas de integrações. Um passo de código resolve; sem ele, fica-se à espera de um fornecedor que talvez nunca o construa.
Lógica que não cabe num "se isto, então aquilo". Regras de preço com escalões, aprovações que escalam por vários critérios em simultâneo, validações que dependem do histórico. É possível montar isto visualmente, mas o resultado costuma ser um emaranhado que ninguém consegue ler seis meses depois.
Dados que não podem sair da infraestrutura. Registos clínicos, dados de recursos humanos, informação sujeita a contrato com cliente. Plataformas que correm em servidor próprio resolvem o problema pela raiz.
Volume que torna o preço por tarefa insustentável. A partir de certo ponto, a fatura mensal paga o esforço de montar algo mais controlado.

Se nenhum destes sinais se aplica ao seu caso, o low-code é complexidade a mais, e complexidade a mais tem um custo que só aparece na manutenção.

O n8n é interessante precisamente por cobrir as duas posturas: usa-se em modo visual sem escrever nada e, quando é preciso, abre-se o nó Code. Se ainda não conhece a ferramenta, vale a pena perceber o que é o n8n e como funciona o modelo fair-code, sobretudo pela parte do alojamento em servidor próprio.

A pergunta que quase ninguém faz antes de assinar

Como é que se sai daqui?

Sejamos honestos sobre o que não se sabe: não existe um número público fiável para o custo de migrar de uma plataforma para outra. Os valores que circulam vêm quase todos de fornecedores concorrentes e não são auditáveis. Repeti-los aqui seria dar-lhes uma credibilidade que não têm.

Por isso a recomendação não é decorar uma estatística. É fazer um teste, e demora dez minutos: antes de assinar, peça a exportação de um fluxo e veja o que recebe. Se for um ficheiro legível, com a lógica visível, tem uma saída. Se for um formato proprietário que só aquela plataforma lê, já sabe qual é o custo de saída — reconstruir tudo de raiz.

Faça a mesma pergunta aos dados. Onde vivem, em que formato saem, quanto tempo demora a extraí-los. Uma plataforma que responde mal a estas três perguntas está a vender-lhe mais dependência do que automatização, independentemente de ser no-code ou low-code.

Uma ordem de decisão que funciona

A escolha entre no-code e low-code não deve ser o primeiro passo. Deve ser o último.

Escolha o processo. Um só, o que dói mais. Se precisar de candidatos, temos uma lista de processos que compensa automatizar primeiro.
Meça-o. Quantas vezes corre por mês, quantos passos tem, quantas pessoas toca.
Verifique os conectores. Os sistemas que precisa de ligar estão na lista da plataforma? Se um deles não estiver, a resposta já se decidiu sozinha.
Teste a exportação. Antes de assinar, não depois.
Só então escolha a categoria. A esta altura, provavelmente já é óbvia.

Seguindo esta ordem, a decisão deixa de ser filosófica e passa a ser uma consequência de factos que já tem em mãos.

Fica uma pergunta concreta para levar à próxima reunião de equipa: qual é o processo que executam mais vezes por semana e o que é que, nesse processo, nenhum bloco visual conseguiria fazer? Se conseguir responder à segunda parte com um exemplo real, precisa de low-code. Se não conseguir, comece em no-code e poupe o resto do orçamento para o processo seguinte.