Quase toda conversa sobre low code começa pela construção: quanto tempo leva, quem consegue montar, quanto custa a licença. É a parte fácil. A plataforma certa, nas mãos de alguém que entende o processo, entrega um app interno funcionando em poucas semanas — e o piloto costuma dar certo.
O que trava o projeto aparece depois, quando alguma coisa sai: a pessoa que criou o app, a regra que o permitia existir ou a própria plataforma. Este artigo explica o que é low code, onde ele vale a pena e onde não vale, e organiza a decisão pelas três saídas — cada uma com a regra que o próprio fornecedor documenta, e com o checklist para entrar já sabendo como sair.
O que é low code?
Low code é uma forma de desenvolver software em que a maior parte da aplicação é montada numa interface visual: você desenha as telas, define as tabelas de dados, liga os passos de um fluxo e configura regras por formulários e blocos, em vez de escrever tudo linha a linha. O código continua existindo, mas entra como complemento — numa fórmula, numa integração específica, num trecho de lógica que o visual não cobre.
A palavra "low" é literal: pouco código, não nenhum. Isso define para quem a ferramenta serve. Um analista de operações com raciocínio lógico consegue construir um app simples de aprovação de despesas; um desenvolvedor consegue construir sistemas bem maiores, com velocidade que não teria no código tradicional. A plataforma cuida do que é repetitivo — hospedagem, banco de dados, login, telas responsivas — e a equipe se concentra na regra de negócio.
O nome é recente; a ideia, não. A página da AWS sobre low code situa o surgimento do termo em 2016 e liga sua origem ao desenvolvimento rápido de aplicações dos anos 1990, passando pelas plataformas móveis dos anos 2000. Antes disso, planilhas com macros, geradores de formulário e bancos de dados visuais já faziam, em escala menor, o que o low code corporativo faz hoje.
Qual a diferença entre low code, no code e desenvolvimento tradicional?
As três abordagens não competem pelo mesmo projeto. Elas se separam por quem constrói, até onde se pode personalizar e quanto a empresa fica presa à ferramenta escolhida.
| No code | Low code | Desenvolvimento tradicional | |
|---|---|---|---|
| Quem constrói | área de negócio, sem programar | analistas e desenvolvedores, com apoio de TI | equipe de desenvolvimento |
| Como se constrói | só por interface visual | visual, com código onde o visual não alcança | código escrito do zero ou sobre frameworks |
| Até onde personaliza | até o limite da ferramenta | bem além, por extensões e código próprio | sem limite além do orçamento |
| Velocidade na largada | a maior | alta | a menor |
| Uso típico | site, formulário, protótipo, MVP | apps internos, automações, integração com sistemas corporativos | produto principal, sistemas críticos e de alta escala |
| Dependência da ferramenta | alta | alta, com regras de governança do fornecedor | baixa: o código é da empresa |
Organizado pela Alliance
A fronteira entre no code e low code ficou borrada: muitas plataformas visuais aceitam código em algum ponto, e muitas plataformas low code têm modos em que ninguém programa. O que separa na prática é o público-alvo. No code mira quem não programa e nunca vai programar; low code mira equipes que precisam de velocidade sem abrir mão de integração com os sistemas corporativos e do controle da TI.
Sobre o lado no code, em especial o modelo de cobrança por consumo que faz a conta subir quando o app dá certo, escrevemos em ferramentas no-code: a conta que chega depois que o app funciona. Aqui o foco é o low code corporativo — e o tipo de dependência que ele cria.
Quais são as plataformas low code mais usadas?
O mercado se divide em dois grupos. O primeiro é o das plataformas que vêm junto de um ecossistema que a empresa já usa; o segundo, o das plataformas independentes, especializadas em desenvolvimento de aplicações.
- Microsoft Power Platform (Power Apps, Power Automate e ferramentas vizinhas): a porta de entrada mais comum em empresas que já usam Microsoft 365, porque as licenças e os dados já estão lá.
- OutSystems: plataforma voltada a aplicações corporativas de maior porte, usada por equipes de TI para sistemas completos, web e mobile.
- Mendix: concorrente direta nesse segmento de aplicações corporativas.
- Oracle APEX: ferramenta low code que roda sobre o banco de dados Oracle, comum onde esse banco já é o padrão.
- Salesforce e Appian: low code acoplado a CRM e a gestão de processos, respectivamente.
A pergunta "qual é a melhor plataforma low code" não tem resposta fora de contexto. A que mais pesa na escolha é onde os dados da empresa já estão, porque integração é o que mais consome tempo em qualquer projeto. A segunda é a que este artigo trata: o que acontece com os apps quando algo muda em volta deles.
Onde o low code vale a pena — e onde não vale?
O low code rende mais onde o processo é da empresa, muda com frequência e hoje vive numa planilha, num e-mail ou num sistema que ninguém tem coragem de mexer. Exemplos típicos na prática:
- aprovações internas — compras, férias, reembolso, descontos comerciais fora da tabela;
- apps de campo — vistoria, inspeção, checklist de visita com foto e geolocalização;
- portais simples para parceiros e fornecedores enviarem documentos e acompanharem status;
- automações que ligam sistemas que não conversam, como levar o pedido do e-commerce para o ERP e avisar o comercial;
- painéis operacionais que substituem o relatório montado à mão toda segunda-feira.
E ele costuma não valer a pena quando o app é o produto principal da empresa, quando precisa atender milhões de usuários externos com desempenho fino, quando a regra de negócio é tão particular que metade do projeto vira código escrito dentro da plataforma, ou quando a empresa não tem ninguém para governar o que foi construído. Nesses casos, o ganho de velocidade da largada é pago com juros depois.
A consultoria de low-code e no-code da Alliance começa exatamente por essa triagem: quais processos entram na plataforma, quais pedem integração com o que já existe e quais pedem desenvolvimento tradicional.
Por que o projeto low code trava na saída, e não na construção?
Porque o low code resolve bem o problema de construir e transfere para outro lugar o problema de manter. Numa aplicação tradicional, o código fica num repositório da empresa, roda num servidor contratado por ela e usa credenciais técnicas. Numa plataforma low code, o app mora dentro de um ambiente do fornecedor, costuma usar a conta de quem o criou para se conectar aos dados e obedece às políticas que a TI configura para aquele ambiente.
Nada disso é defeito. É o que permite que um analista monte um fluxo em uma tarde. Mas significa que o app depende de três coisas que não estão no desenho de ninguém quando o piloto começa: a pessoa, a regra e a plataforma. Quando uma delas sai do lugar, o app pode parar.
A Oracle, no guia mais completo entre os primeiros resultados do Google sobre o tema, menciona em uma frase que a lógica de uma plataforma não pode ser levada para outra. É verdade, e é só a terceira saída. As outras duas acontecem muito antes — e acontecem com a empresa satisfeita com a plataforma.
O que acontece com o app quando quem o criou sai da empresa?
É a saída mais comum e a menos planejada. No low code, a pessoa que cria um app ou um fluxo vira, por padrão, a dona dele. Se ela é a única dona e deixa a empresa, o fluxo fica sem responsável — e, em muitos casos, a conta dela era a que dava acesso aos dados.
Repare no mecanismo. O fluxo não falha porque a pessoa saiu; falha porque a conexão que ele usava — o acesso ao e-mail, à planilha, ao CRM — estava amarrada à conta dela, e a conta foi desativada no desligamento, como manda qualquer política de segurança. O próprio processo correto de RH é o que derruba a automação.
E o problema costuma ser descoberto pelo sintoma, não pela causa: o relatório que não chegou, o pedido que não entrou no sistema, o cliente que não recebeu o aviso. Até alguém ligar a falha ao desligamento de três semanas atrás, o processo ficou parado.
Vale uma ressalva de precisão: a regra acima é a dos fluxos do Power Automate. Para os apps do Power Apps, o comportamento quando o dono sai segue outras regras, e não deve ser presumido igual. A lição, porém, vale para qualquer plataforma: todo app em produção precisa de mais de um dono.
O que acontece quando a TI muda a regra de dados?
A segunda saída é mais sutil, porque acontece com todo mundo na empresa. Em plataformas corporativas, a TI define políticas de dados: quais conectores podem ser usados juntos, quais ficam separados, quais são bloqueados. É o que impede, por exemplo, que um fluxo pegue dados do CRM e os envie para um serviço externo não aprovado.
Essas políticas são necessárias — e mudam. Uma auditoria de segurança, uma adequação à LGPD ou um incidente fazem a TI apertar a regra. O efeito sobre o que já foi construído está documentado.
Na prática, isso quer dizer que um app que funcionava na sexta-feira pode estar suspenso na segunda, sem que ninguém da área de negócio tenha mexido nele. A TI fez o trabalho certo, a área fez o trabalho certo, e o processo parou no meio. O que faltou foi a conversa entre os dois antes de o app ir para produção.
No low code, o app raramente quebra porque alguém errou. Ele quebra porque alguém fez a coisa certa em outro departamento.
A saída para essa saída é de desenho, não de ferramenta: separar ambientes (um para experimentação, outro para o que está em produção), definir a política de dados antes de liberar a construção e combinar que mudança de política passa por um inventário dos apps afetados. É o mesmo raciocínio de integração de sistemas: o dado precisa ter dono e regra antes de ter fluxo.
Dá para tirar o código de uma plataforma low code?
Depende da plataforma, e a resposta curta costuma ser "não do jeito que você imagina". Na maioria das ferramentas, o que você constrói é configuração guardada dentro da plataforma, não um código-fonte que se leva para outro lugar. Trocar de fornecedor significa, em geral, reconstruir.
Há plataformas que documentam um caminho de saída. É o caso da OutSystems, e as condições dele mostram por que a saída precisa ser planejada no começo, não no fim.
Ou seja: existe porta de saída, mas ela é para a empresa inteira, de uma vez, e passa antes por uma migração de infraestrutura. Não serve para "tirar só aquele sistema que cresceu demais". E essa regra é específica da OutSystems 11 — a versão em nuvem mais recente da empresa e as demais plataformas têm regras próprias, que precisam ser lidas antes da assinatura.
A pergunta útil na hora da escolha, então, não é "dá para exportar?". É: se precisarmos sair, o que sai, em que formato, de quantos apps de uma vez e com que esforço? Se a resposta for "reconstruímos tudo", tudo bem — desde que a decisão seja consciente e o dado esteja num lugar de onde se possa tirá-lo.
Como entrar no low code já com a saída desenhada?
A boa notícia é que as três saídas se previnem com decisões baratas, tomadas antes do primeiro app. Nenhuma exige ferramenta extra; todas exigem que alguém as escreva.
1. Dono secundário em tudo que roda em produção
Todo app e todo fluxo que alguém usa no trabalho real tem pelo menos dois proprietários, e um deles é de uma equipe, não de uma pessoa. A regra entra no checklist de publicação: sem segundo dono, não vai para produção.
2. Conta de serviço nas conexões críticas
As conexões com CRM, ERP, e-mail transacional e bancos de dados usam uma conta técnica da empresa, não o login de quem montou o fluxo. Assim, o desligamento de uma pessoa não desliga a integração. É a mesma prática que a TI já aplica aos sistemas tradicionais, estendida ao low code.
3. Ambiente e política de dados antes da construção
Separe um ambiente de testes, livre para experimentar, de um ambiente de produção com política de dados já definida. O app nasce dentro da regra e não corre o risco de ser suspenso por ela depois. E combine com a TI que toda mudança de política começa por listar os apps que ela afeta.
4. Inventário vivo
Uma lista simples — nome do app, dono principal, dono secundário, dados que usa, processo que sustenta — revisada a cada trimestre. Os centros de administração das plataformas corporativas ajudam a montar essa lista, mas a pergunta "qual processo para se isto parar?" só a área de negócio responde.
5. Plano de saída por escrito
Uma página basta: onde ficam os dados (de preferência num banco que a empresa controla), o que a plataforma permite exportar, o que teria de ser reconstruído e uma estimativa grosseira do esforço. Não é pessimismo: é o mesmo documento que se exige de qualquer fornecedor crítico.
Quais os erros mais comuns com low code?
| Erro | O que acontece | Como evitar |
|---|---|---|
| Deixar cada área construir no mesmo ambiente | teste e produção se misturam e ninguém sabe o que é crítico | ambiente de testes separado do de produção |
| Conectar tudo com a conta pessoal de quem criou | o desligamento da pessoa derruba a integração | conta de serviço nas conexões críticas |
| Um único dono por app ou fluxo | fluxo órfão, descoberto só quando falha | dono secundário como regra de publicação |
| Mudar a política de dados sem inventário | apps suspensos sem aviso para a área de negócio | listar os apps afetados antes de mudar a regra |
| Escrever metade do sistema em código dentro da plataforma | perde-se a velocidade do low code e mantém-se a dependência | mover para desenvolvimento tradicional o que é código de verdade |
| Escolher a plataforma sem ler a regra de saída | descobre-se o custo de sair só na hora de sair | plano de saída por escrito antes da assinatura |
Leitura da Alliance a partir da documentação de Microsoft e OutSystems citada neste artigo
Há um erro de fundo que atravessa todos os outros: tratar low code como assunto só da área de negócio ou só da TI. Quando a área constrói sem a TI, as saídas 1 e 2 aparecem. Quando a TI centraliza tudo, o low code perde a razão de existir — a velocidade — e vira mais uma fila de chamados.
Como a IA muda o low code?
As principais plataformas passaram a incluir assistentes de IA que geram telas, tabelas, fórmulas e fluxos a partir de uma descrição em texto. Na prática, isso encurta ainda mais a largada: o primeiro rascunho de um app sai de um parágrafo bem escrito.
O efeito colateral é previsível. Se ficou mais fácil construir, mais apps serão construídos, por mais gente — e as três saídas se multiplicam na mesma proporção. A IA não resolve a pergunta "quem é o dono disso?"; ela só faz a pergunta aparecer mais vezes. É o mesmo movimento que discutimos em vibe coding: onde cabe e onde não cabe dentro da empresa, agora dentro de uma plataforma com governança própria.
Por isso, a governança do low code tende a ficar mais importante com a IA, não menos. O checklist de entrada continua o mesmo; o que muda é a frequência com que ele precisa ser aplicado.
Por onde começar hoje
- Liste os apps e fluxos low code que já existem na empresa — quase sempre há mais do que a TI imagina.
- Para cada um, anote o processo que ele sustenta e o que acontece se parar amanhã.
- Verifique quantos têm um único dono e quantos usam conexões com conta pessoal; comece pelos críticos.
- Separe o ambiente de testes do ambiente de produção e defina a política de dados deste último.
- Antes do próximo app, aplique o checklist: dono secundário, conta de serviço, ambiente certo e plano de saída.
- Na escolha ou renovação da plataforma, peça ao fornecedor a regra de saída por escrito, com formato e escopo.
Low code é uma das formas mais rápidas de tirar um processo da planilha, e vale a pena na maioria das empresas que o adotam com critério. O que separa o projeto que escala do que vira passivo é ter desenhado as saídas enquanto ainda era barato.
Se a dúvida é maior — onde a tecnologia e a automação da empresa estão maduras, onde estão frágeis e o que priorizar —, o diagnóstico de marketing gratuito mapeia a maturidade por área, incluindo tecnologia e automação, e devolve um plano com os próximos passos.