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

> Low-code ou desenvolvimento tradicional? Compare velocidade, limites de regra e volume, licença por usuário, dependência da plataforma e como sair dela.

Fonte: https://pervian.tech/blog/low-code-ou-desenvolvimento-sob-medida · Pervian Tech · publicado em 2026-10-01

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:

| Critério | Low-code / no-code | Desenvolvimento sob medida |
|---|---|---|
| Velocidade para a primeira versão | Muito alta em processos simples | Menor no início, depende do escopo |
| Regras de negócio complexas | Ficam difíceis de manter e testar | Expressas e testadas em código |
| Volume de dados e transações | Limitado pelos limites da plataforma | Dimensionado para o caso real |
| Integrações | Fáceis com conectores prontos, difíceis fora deles | Qualquer sistema com API ou arquivo |
| Custo ao crescer | Cresce com usuários, execuções ou registros | Cresce com infraestrutura e evolução |
| Dependência | Alta: lógica presa ao formato da plataforma | Baixa, se o código-fonte for da empresa |
| Saída | Normalmente reconstrução | Troca de fornecedor sem reescrever, com código documentado |

## 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](https://pervian.tech/blog/como-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](https://pervian.tech/blog/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](https://pervian.tech/blog/zapier-make-ou-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](https://pervian.tech/blog/rpa-ou-integracao-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](https://pervian.tech/blog/propriedade-do-codigo-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](https://pervian.tech/blog/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](https://pervian.tech/blog/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](https://pervian.tech/blog/bubble-ou-codigo-proprio).

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](https://pervian.tech/solucoes/sistema-de-gestao-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](https://pervian.tech/blog/divida-tecnica-explicada-para-gestores) 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](https://pervian.tech/servicos/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](https://pervian.tech/blog/categoria/engenharia). Se o seu aplicativo low-code começou a travar ou você está decidindo por onde começar, [conte o seu caso](https://pervian.tech/#contato).