Projeções da Gartner estimam que, até 2025, 70% das novas aplicações corporativas serão construídas com plataformas low-code ou no-code, contra cerca de 25% em 2020, e observações de mercado no Brasil indicam que essas plataformas já entraram no radar de prioridade de boa parte dos CIOs. O dado descreve um deslocamento real do ponto em que software passa a existir, que sai das mãos de equipes de engenharia e migra pra áreas de operação, marketing, RH e atendimento, levando consigo tanto a velocidade de entrega quanto um conjunto novo de dependências estruturais que o discurso de democratização tende a não nomear.
O comportamento observado em empresas que adotam essas plataformas segue um padrão consistente. Uma área de negócio identifica um fluxo manual e monta um formulário conectado a uma planilha ou a um banco gerenciado pela própria plataforma, com duas ou três integrações prontas plugadas no caminho, e publica uma aplicação que antes dependeria de um backlog de seis meses na fila de TI. O resultado é que a operação passa a existir, com tempo de resposta saindo de trimestres pra dias, e pessoas sem formação em engenharia passam a exercer, de fato, uma forma de autoria sobre o sistema em que trabalham. Nesse recorte, na minha avaliação, o empoderamento é concreto, e ignorar isso seria desonesto com quem nunca teve acesso a um time de desenvolvimento disposto a priorizar o problema.
A mesma dinâmica, observada ao longo do tempo, revela que a abstração que permite a entrada barata também define os termos da permanência. Plataformas low-code e no-code operam entregando um modelo pronto da pilha inteira (dados, autenticação, lógica, interface e hospedagem), e esse modelo se torna o contrato implícito de tudo que é construído sobre ele. A aplicação que foi feita em dois dias carrega, a partir dali, o formato de dados, o motor de automação, o provedor de identidade e a política de preços que a plataforma define, e nenhum desses elementos é negociável pela área que construiu a solução.
A dependência se manifesta em momentos distintos, mas converge pros mesmos pontos de pressão. Os dados ficam armazenados em estruturas proprietárias cuja exportação existe no papel mas degrada em relações, tipos e histórico quando executada de fato, enquanto os fluxos desenhados visualmente não possuem equivalente portável, o que faz com que qualquer migração futura seja, na prática, uma reimplementação. Sobre essas duas camadas técnicas se acopla uma camada comercial, em que o preço por usuário, por execução ou por registro se ajusta depois que a operação já depende do sistema, e o custo de sair passa a ser maior que o custo de aceitar o reajuste.
O trade-off que se desenha é direto. A plataforma reduz a barreira de entrada ao custo de transferir pra fora da organização decisões estruturais sobre dados, integrações e continuidade, enquanto código escrito internamente preserva essas decisões ao custo de exigir equipe, tempo e disciplina de manutenção que muitas áreas não têm nem terão. Tratar essa escolha como binária entre autonomia e dependência distorce o que está em jogo, porque toda stack moderna opera com algum grau de dependência de fornecedor, e a diferença relevante está no tamanho da superfície de acoplamento e na existência de um caminho de saída que preserve o que foi construído.
Em um cenário recente, uma operação de atendimento em uma empresa de médio porte construiu, em no-code, um sistema completo de triagem de chamados integrado a WhatsApp e CRM, com painel de indicadores, entregue em semanas por uma analista sem background técnico. A solução funcionou por quase dois anos e absorveu crescimento de volume, reduzindo o tempo médio de resposta a um terço do anterior, até que a plataforma alterou o modelo de cobrança por contato ativo e o custo mensal passou a inviabilizar a operação no formato existente. A migração pra uma stack própria levou seis meses e exigiu contratação de dois desenvolvedores, embora tenha recuperado apenas parte das automações originais porque o motor de regras visuais não tinha correspondente direto fora daquele ambiente. Ainda que a aplicação tenha existido e gerado valor real durante o período em que operou, ao mesmo tempo deixou a organização mais exposta do que estaria se tivesse, desde o início, separado a camada de dados da camada de lógica visual.
Pra mim, democratização via abstração só se sustenta quando a pessoa que constrói mantém, em algum grau, controle sobre os dados que produz e sobre o caminho de evolução do que construiu. Quando a ferramenta exporta esquemas em formato aberto, expõe API estável e cobra de forma previsível, ela amplia a agência de quem usa, até porque preserva a possibilidade de sair carregando o que foi construído. Quando ela prende os dados em formato opaco e ajusta o preço em função da dependência instalada, inverte o vetor, e o que se vende como acesso opera como captura. O grau de empoderamento de uma plataforma low-code ou no-code é, na minha avaliação, uma função do custo de saída que ela impõe, e esse custo raramente aparece no material de venda que sustenta o discurso de democratização.