Low-code ou desenvolvimento sob medida: quando usar cada um

A área comercial montou em duas semanas um aplicativo de aprovação de descontos numa plataforma low-code. Funcionou, todo mundo gostou, e logo vieram pedidos: puxar o limite de crédito do ERP, aplicar regras diferentes por região, gerar o pedido automaticamente depois da aprovação. Seis meses depois, cada mudança leva mais tempo que a anterior, a licença cresceu junto com o número de usuários e ninguém sabe direito o que acontece se a empresa quiser trocar de ferramenta.

Esse roteiro é comum, e não significa que low-code foi um erro. Significa que a escolha foi feita olhando só para o começo do ciclo de vida do sistema. A comparação útil entre low-code e desenvolvimento tradicional não é "qual é melhor", e sim em que fase e para que tipo de processo cada um compensa, e o que acontece quando o processo cresce.

Este texto responde a essa pergunta pelo ciclo de vida: velocidade inicial, limites de regra e de volume, custo por usuário, dependência da plataforma e saída.

A resposta curta: low-code ou desenvolvimento tradicional?

Use low-code quando o processo é simples, interno, com poucos usuários, regras estáveis e pouca integração, e quando a velocidade de colocar algo de pé vale mais que controle total. Use desenvolvimento sob medida quando o sistema é parte do diferencial do negócio, tem regras complexas ou que mudam com frequência, precisa falar com vários sistemas, atende clientes externos ou vai crescer em volume e em número de usuários.

Entre os dois extremos existe o modelo híbrido, que costuma ser o mais sensato para empresas médias: um núcleo em código, com APIs bem definidas, e aplicativos periféricos em low-code consumindo esse núcleo.

A tabela resume as diferenças que pesam na decisão:

Por que low-code atrai gestores

A atração é legítima. Plataformas low-code e no-code entregam três coisas que o desenvolvimento tradicional demora a entregar:

• Velocidade. Um formulário com aprovação, uma lista com filtros e um painel simples ficam prontos em dias.
• Autonomia. A área de negócio resolve sem entrar na fila da TI. Quem conhece o processo é quem constrói.
• Custo inicial baixo. Não há projeto, contrato de desenvolvimento nem infraestrutura para montar. Paga-se a licença e começa.

Para muitos problemas, isso basta. O risco aparece quando a solução que nasceu para resolver um incômodo pequeno vira, sem que ninguém decida isso, o sistema central de um processo crítico.

Onde ele brilha: protótipos e processos simples

Há usos em que low-code é a escolha certa, e não um quebra-galho:

• Fluxos internos de aprovação. Solicitação de compra abaixo de um limite, pedido de férias, reembolso de despesas, requisição de material.
• Formulários e coleta de dados. Checklist de visita, pesquisa interna, cadastro de ocorrências.
• Protótipos para validar uma ideia. Antes de investir num sistema, montar uma versão rápida para ver se o processo faz sentido e se as pessoas usam. Esse uso combina bem com a lógica de definir o escopo de um MVP: validar com o mínimo e só depois construir para durar.
• Substituir uma planilha frágil em um processo pequeno, com poucos usuários e regras estáveis. Quando a planilha já é o coração da operação, a conversa muda, como mostramos em substituir planilhas por sistema.

O que esses casos têm em comum: poucos usuários, regras que cabem numa frase, volume modesto e baixo impacto se o aplicativo ficar fora do ar por algumas horas.

Limites: regras complexas, volume e integrações

Os problemas raramente aparecem na primeira versão. Eles aparecem na décima mudança.

Regras de negócio que crescem

Low-code representa regras com blocos visuais, fórmulas e condições encadeadas. Para "se o desconto passar de tal limite, pedir aprovação do gerente", funciona bem. Para uma política comercial com exceções por cliente, região, canal, tabela de preço e vigência, o fluxo visual vira um emaranhado que só quem montou entende.

Em código, a mesma regra fica num lugar só, com nome, histórico de alterações e testes automatizados que avisam quando uma mudança quebra outro caso. Muitas plataformas low-code oferecem suporte limitado a testes automatizados de regra, e, na prática, a validação costuma ser manual, a cada alteração.

Volume e desempenho

Plataformas low-code têm limites de registros por tabela, de execuções de automação por mês, de chamadas a APIs e de tempo de processamento. Esses limites constam da documentação, mas nem sempre entram na conversa de venda. Um aplicativo que processa algumas dezenas de pedidos por dia vai bem. O mesmo aplicativo com milhares de itens, histórico de anos e relatórios cruzando tudo começa a ficar lento, e as opções costumam ser poucas: contratar um plano maior, arquivar dados antigos ou reduzir o que o aplicativo faz.

Integrações fora do catálogo

Conectores prontos resolvem bem as integrações populares. O problema é o ERP antigo, o sistema do fornecedor que só aceita arquivo, a API com autenticação fora do padrão ou a integração que precisa de fila, reprocessamento e controle de erros. Nesses casos, sobra em geral um conector genérico de chamadas HTTP, e o tratamento de falhas (repetir, registrar, avisar alguém) precisa ser improvisado no fluxo visual. A comparação entre Zapier, Make e n8n mostra onde cada ferramenta de automação para.

Muitas vezes a saída encontrada é automatizar cliques na tela de outro sistema. Isso tem lugar, mas tem custos de manutenção que comparamos em RPA ou integração via API.

Licença por usuário e dependência da plataforma

O custo que cresce com o sucesso

O modelo de cobrança da maioria das plataformas é por usuário, por aplicativo, por execução ou por volume de dados, e frequentemente uma combinação disso. No começo, com dez usuários internos, o valor é pequeno. Quando o aplicativo funciona e se espalha para toda a operação, ou quando a empresa quer abrir acesso para clientes, representantes ou fornecedores, a conta cresce de forma proporcional.

O desenvolvimento sob medida tem lógica oposta: o investimento está concentrado na construção e na evolução, e o custo de infraestrutura cresce com o uso real, não com o número de pessoas que fazem login. Para comparar de forma honesta, projete o custo dos dois caminhos em um horizonte de alguns anos, com o número de usuários que você espera ter, e não com o de hoje.

Lock-in: a lógica fica presa ao formato da plataforma

Em low-code, a empresa normalmente consegue exportar os dados. O que não sai é a lógica: fluxos, telas, regras e automações existem no formato da plataforma e não rodam em nenhum outro lugar. Se o fornecedor mudar a política de preço, descontinuar um recurso ou for adquirido, a empresa tem duas opções: aceitar ou reconstruir.

No código sob medida, a pergunta equivalente é sobre quem é dono do código-fonte, e ela se resolve no contrato. Detalhamos o que exigir em propriedade do código-fonte no contrato.

Segurança e governança de apps criados pelas áreas

A autonomia das áreas tem um lado que a TI conhece bem: aplicativos que ninguém inventariou, com dados de clientes, permissões amplas demais e conexões com sistemas críticos criadas com a senha de um funcionário que já saiu da empresa.

Os riscos mais comuns:

• Dados pessoais sem controle. Um aplicativo de cadastro com CPF, telefone e endereço de clientes também está sujeito à LGPD, mesmo que tenha sido montado por alguém do comercial. Os cuidados de LGPD no desenvolvimento de sistemas valem aqui também.
• Permissões frouxas. Compartilhamento com "todos da empresa" ou com links públicos por conveniência.
• Credenciais pessoais em integrações. O fluxo para de funcionar quando a pessoa muda de cargo, ou continua funcionando com acesso que ela não deveria mais ter.
• Sem rastreabilidade. Ninguém sabe quem alterou um registro ou uma regra. Em processos sensíveis, isso é um problema de auditoria, como explicamos em controle de acesso e trilha de auditoria.

Low-code com governança é possível. Exige um inventário dos aplicativos, um responsável por cada um, regras sobre quais dados podem ser usados, contas de serviço para integrações e uma revisão periódica do que está em uso.

Como sair de uma plataforma low-code

Se o aplicativo já passou do ponto, a migração precisa ser planejada para não parar a operação. O caso do Bubble está em migrar do Bubble para código próprio.

1. Inventarie o que existe. Telas, fluxos, automações, integrações, usuários e permissões. Muitas regras estão escondidas em fórmulas e condições espalhadas.
2. Documente as regras em linguagem de negócio. Antes de reescrever qualquer coisa, escreva o que o processo faz, incluindo as exceções que só aparecem em casos raros.
3. Exporte e audite os dados. Verifique campos duplicados, registros inconsistentes e anexos. É o momento de limpar.
4. Defina o núcleo que vai para código. Nem tudo precisa sair. Priorize o que tem regra complexa, volume alto ou integração crítica.
5. Construa o novo sistema com APIs. Assim, aplicativos low-code que continuarem existindo podem consumir o núcleo em vez de duplicar regras.
6. Migre por partes, com convivência. Rode os dois em paralelo por um período, compare resultados e desligue o antigo só depois de validar.
7. Planeje o fim da licença. Alinhe a data de desligamento com o contrato da plataforma para não pagar dois sistemas por mais tempo que o necessário.

O prazo depende do tamanho do que foi construído e da qualidade dos dados. Pode ser de algumas semanas para um aplicativo isolado até alguns meses para um processo central, e só um levantamento inicial permite estimar com responsabilidade.

Modelo híbrido: o melhor dos dois

Para muitas empresas médias, a melhor resposta não é escolher um lado. É dividir responsabilidades:

• Núcleo em código: cadastros mestres, regras de negócio críticas, cálculos fiscais e comerciais, integrações com ERP, bancos e parceiros. É onde estão o diferencial e o risco, e onde testes, versionamento e controle de acesso fazem diferença. Um sistema de gestão sob medida costuma ocupar esse papel.
• Periferia em low-code: formulários, aprovações simples, painéis de uso interno e protótipos, consumindo o núcleo por APIs e sem duplicar regra.

A regra que mantém o modelo saudável: regra de negócio importante mora num lugar só. Se o cálculo do desconto existe no núcleo e também numa fórmula do aplicativo low-code, cedo ou tarde os dois vão divergir, e a dívida acumulada se comporta como a dívida técnica de qualquer sistema.

Critérios de decisão: checklist

Responda para cada processo que você está pensando em automatizar:

• O processo é interno e envolve poucos usuários, ou vai atender clientes e parceiros?
• As regras cabem em poucas frases, ou têm exceções por cliente, região, canal e vigência?
• O volume esperado em dois ou três anos cabe nos limites documentados da plataforma?
• As integrações necessárias existem como conectores prontos e confiáveis?
• O custo projetado da licença, com o número de usuários futuro, ainda faz sentido?
• Se a plataforma ficar mais cara ou for descontinuada, a empresa consegue reconstruir sem parar a operação?
• Há dados pessoais ou financeiros envolvidos? Quem responde pela segurança?
• O processo é parte do diferencial competitivo da empresa?

Se a maioria das respostas aponta para simplicidade, poucos usuários e baixo impacto, low-code é uma boa escolha. Se aponta para regra complexa, volume, integração crítica ou diferencial do negócio, o caminho é código sob medida, mesmo que comece com um protótipo em low-code para validar a ideia.

Perguntas frequentes

Qual a diferença entre low-code e no-code?

Low-code e no-code são plataformas que montam aplicativos com blocos visuais. O no-code mira quem não programa e dispensa código; o low-code permite acrescentar trechos de código para o que os blocos não cobrem. Diante do desenvolvimento sob medida, os dois têm vantagens e limites parecidos, como licença por uso e dependência da plataforma.

Dá para exportar um aplicativo low-code e rodar em outro lugar?

Normalmente, só os dados. Em plataformas low-code, a empresa costuma conseguir exportar os registros, mas fluxos, telas, regras e automações existem no formato da plataforma e não rodam em outro lugar. Por isso, sair de uma plataforma low-code geralmente significa reconstruir a lógica, de preferência por partes e com os dois sistemas em paralelo.

Low-code é mais barato que desenvolvimento sob medida?

No começo, quase sempre. A plataforma low-code dispensa projeto e infraestrutura, mas a licença costuma crescer com usuários, execuções ou registros. No desenvolvimento sob medida, o investimento se concentra na construção e na evolução. A comparação honesta projeta o custo dos dois caminhos por alguns anos, com o número de usuários esperado.

Quanto tempo leva para migrar de low-code para código próprio?

Depende do tamanho do que foi construído e da qualidade dos dados. A migração de uma plataforma low-code pode levar de algumas semanas, para um aplicativo isolado, a alguns meses, para um processo central, e só um levantamento inicial das telas, regras e integrações permite estimar o prazo com responsabilidade.

Aplicativo low-code criado pela área de negócio precisa seguir a LGPD?

Sim. Um aplicativo low-code com CPF, telefone ou endereço de clientes está sujeito à LGPD como qualquer sistema, mesmo que tenha sido montado por alguém do comercial. Isso pede inventário dos aplicativos, um responsável por cada um, permissões restritas, contas de serviço nas integrações e revisão periódica do que está em uso.

Como a Pervian Tech trabalha a escolha de tecnologia

Na Pervian Tech, a escolha entre low-code, código ou modelo híbrido faz parte do trabalho de arquitetura de software. Começamos pelo processo, não pela ferramenta: levantamos regras, volume, integrações, usuários e riscos, e recomendamos o que faz sentido para o ciclo de vida inteiro, inclusive quando a resposta é manter o low-code e organizar a governança. Quando o caminho é código, desenhamos o núcleo com APIs para que as áreas continuem com autonomia sem duplicar regras.

Cada recomendação é sob medida, e o investimento é definido sob consulta depois de um diagnóstico inicial gratuito. Outros textos sobre decisões técnicas estão na categoria engenharia. Se o seu aplicativo low-code começou a travar ou você está decidindo por onde começar, conte o seu caso.