Boa parte das empresas já paga por uma ferramenta de criar sistemas, e nunca abriu o menu onde ela mora.
Quem usa Google Workspace nos planos Business ou Enterprise já tem o AppSheet incluído, sem custo adicional: um construtor de aplicativos que transforma planilha em app de celular, com formulário, fluxo de aprovação e notificação, sem escrever uma linha de código (documentação oficial do Google Workspace). Quem usa Microsoft 365 tem o equivalente no Power Apps e no Power Automate, com um conjunto básico de recursos liberado dentro da licença que a empresa já paga, embora conectores externos e dados fora do Microsoft 365 exijam licença adicional (documentação oficial da Microsoft).
Isso muda uma conta que até pouco tempo só existia com um time de TI contratado: dá para sair de uma planilha de controle manual para um sistema com tela própria, sem orçamento de desenvolvimento. A pergunta deixou de ser “dá para construir sem programador”. A resposta é sim. A pergunta certa é outra: construir o quê, até que ponto, e com qual cuidado.
Do sem código ao código sob medida
As plataformas desse tipo ficam num espectro. Numa ponta, sem código: AppSheet, Power Apps em sua forma mais simples, Glide, Bubble. Quem usa não escreve código, monta telas e regras visualmente. No meio, baixo código: ferramentas como OutSystems, Mendix ou Retool, que ainda são visuais, mas abrem espaço para quem programa estender o que a interface não cobre. Na outra ponta, código sob medida: o sistema escrito do zero, sem limite de personalização, com o custo e o tempo que isso exige.
Estimativas atribuídas à Gartner, repetidas por vários fornecedores do setor mas difíceis de confirmar na fonte original, apontam que a fatia de aplicativos corporativos novos construídos em baixo código teria saltado de menos de 25% em 2020 para algo perto de 75% em 2026, e que a maioria de quem constrói nessas plataformas hoje estaria fora do departamento de TI formal (ver, por exemplo, a compilação da Kissflow e da Joget). Vale tratar esse número como direção de mercado, não como estatística fechada: nenhuma das fontes consultadas linkou o comunicado original da Gartner com esse texto exato.
O que dá para afirmar com mais segurança é o cenário local. A pesquisa “Transformação Digital nos Pequenos Negócios (2026)”, do Sebrae, mostra que 75% das micro e pequenas empresas brasileiras já usam computador no dia a dia da operação, um número estável em relação ao pico de 76% em 2025 e acima dos 70% registrados em 2022 (Agência Sebrae de Notícias). A infraestrutura básica já chegou. A pergunta que resta é o que cada negócio constrói em cima dela, e com que critério.
O caso que mostrou o risco de verdade
Em 2021, a empresa de segurança UpGuard encontrou mais de mil portais construídos no Power Apps, da Microsoft, configurados por padrão para expor dados a qualquer pessoa que soubesse o endereço, incluindo mecanismos de busca. O total chegou a 38 milhões de registros: dado de rastreamento de contato por covid, agendamento de vacina, número de documento de candidato a emprego, nome e e-mail de funcionário. Entre os afetados estavam órgãos públicos, companhias aéreas e a própria Microsoft (reportagem do Dark Reading, The Register).
Não era uma falha de código, no sentido tradicional. Era uma configuração padrão da plataforma, criada por quem montou o app sem saber que ali estava ligado “público” em vez de “interno”. O risco de quem constrói sem escrever código não desaparece, muda de lugar: sai da sintaxe e vai para a configuração, a permissão, o escopo de quem pode ver o quê.
O projeto da OWASP dedicado a esse tipo de risco (hoje incorporado a um projeto mais amplo sobre desenvolvimento por usuários de negócio, o OWASP Citizen Development Top 10) lista dez categorias recorrentes: alguém se passando pelo dono da aplicação, uso indevido de permissão, vazamento de dado e efeito colateral inesperado, falha de autenticação e de comunicação segura, configuração insegura, falha no tratamento de entrada do usuário, componente vulnerável ou não confiável, falha no tratamento de dado e de segredo, falha na gestão de ativos, e falha de registro e monitoramento. Nenhuma dessas categorias exige saber programar para existir. Todas exigem alguém responsável por fechar a porta certa.
O preço de trocar de plataforma depois
Outro risco que só aparece depois, quando trocar já ficou caro: o aprisionamento ao fornecedor. A lógica de negócio construída numa plataforma proprietária, em motor próprio e formato de dado não padrão, raramente sai de lá intacta. Analistas do setor descrevem isso como um aprisionamento arquitetural: tecido no motor de execução, no formato de código gerado e no ecossistema fechado da própria ferramenta (Betty Blocks, fornecedor do setor, então vale ler como alerta de mercado, não como estudo independente).
Antes de adotar uma plataforma para algo que vai crescer, três perguntas evitam a surpresa: dá para exportar meu dado num formato padrão, sem depender de suporte do fornecedor? Existe API documentada para eu me conectar a outro sistema no futuro, sem depender só dos conectores prontos? E se eu quiser sair, o contrato e a arquitetura permitem, ou o dado fica preso lá dentro?
O dado da sua empresa, mesmo pequena, pode virar alto risco
A Resolução CD/ANPD nº 2/2022 define quando um tratamento de dado pessoal conta como de alto risco: quando combina pelo menos um critério geral (tratamento em grande escala, ou que possa afetar significativamente direito e interesse de quem é titular do dado) com pelo menos um critério específico (dado sensível, dado de criança ou de idoso, decisão automatizada, tecnologia emergente). O porte da empresa não isenta (texto da resolução, Participa + Brasil).
Um aplicativo sem código que decide algo automaticamente sobre um cliente (aprovar um cadastro, calcular um valor, priorizar um atendimento) sem revisão humana pode se encaixar nesse critério de decisão automatizada. Se o mesmo app lida com dado de saúde, de criança ou em volume alto, a conta fecha para o critério específico também. Pequeno porte reduz obrigação em alguns pontos da LGPD. Não reduz o risco em si.
O que a prática mostrou, construindo por dentro
A Inteligência para Crescer já passou pelas duas pontas do espectro, por dentro, em produtos próprios e em um projeto para cliente, e os riscos acima deixaram de ser teoria.
Para um cliente catarinense de automação residencial e manutenção elétrica, o sistema de gestão comercial e operacional foi construído em baixo código, sobre AppSheet, Google Sheets e Google Drive. O ganho foi real: de planilha manual para um app com orçamento, ordem de serviço e checklist de execução, em semanas, não em meses. O risco também foi real, e de um tipo específico de baixo código: defeito que só aparece com dado de verdade, nunca num teste em branco (um modelo de documento que saía perfeito vazio e quebrava com conteúdo real dentro), e gravação concorrente que falha em silêncio quando duas automações escrevem no mesmo registro ao mesmo tempo, sem avisar ninguém. A lição que ficou: testar sempre com conteúdo real antes de liberar para quem vai usar, e nunca confiar que “a tela não mostrou erro” significa que o dado está certo.
No Meu Norte, app de controle financeiro pessoal da própria IPC, construído em código próprio (Cloudflare Workers, banco D1, aplicativo instalável), uma revisão de qualidade formal, feita como se fosse auditoria externa, encontrou uma vulnerabilidade real de injeção de script num campo de texto livre, uma regra de limite de usuários que nunca era atualizada no upgrade de plano, e uma validação que existia numa rota e faltava na rota equivalente de edição. Nenhum desses apareceria só lendo o código por cima, sem testar. Código próprio dá controle total sobre a regra de negócio. Não dá, de graça, a disciplina de segurança que esse controle exige, porque o dado ali é financeiro e é de pessoa física.
O PDV Light, outro produto próprio, foi para o lado oposto de propósito: sem banco de dados central, guardando tudo no próprio navegador do aparelho. A escolha simplifica a operação e zera o custo de manter servidor, e troca isso por uma limitação clara, assumida desde o desenho: não sincroniza entre aparelhos diferentes. Simplicidade deliberada, com a limitação dita antes de alguém descobrir sozinho.
E no NFS-e Automatizado, que automatiza a emissão de nota fiscal de serviço em nome do profissional ou da pequena empresa, o risco apareceu num lugar que nenhuma das outras frentes tinha: a ferramenta depende de uma interface que a empresa não controla, o portal de um governo, e uma mudança nele quebra a automação sem aviso prévio. Num ciclo real de testes, uma nota fiscal já emitida e já enviada ao cliente foi emitida de novo, porque duas partes diferentes do mesmo código tinham uma definição levemente distinta do que significava “nota já emitida”. O programa terminou sem erro, com código de saída zero, e o documento fiscal saiu duplicado. A lição, que vale para qualquer automação que gera documento fiscal, financeiro ou contratual: “não deu erro” nunca é prova de que o resultado está certo. É preciso testar de propósito o cenário feio, não só o caminho feliz.
Os cuidados que evitam o prejuízo
Nenhum desses riscos justifica evitar baixo código ou automação. Justifica adotar com critério.
Separar o que pode rodar numa ferramenta de workspace do que exige código dedicado. Processo interno, de baixo risco e baixo volume, cabe bem em AppSheet ou Power Apps. Dado sensível, decisão automatizada sobre cliente, ou o que diferencia a empresa no mercado, pede um projeto com o mesmo rigor de um sistema bancário.
Nunca deixar credencial pessoal dentro de uma automação. Conta de serviço, não login de alguém da equipe. Quando essa pessoa sai da empresa, a automação não pode sair com ela.
Testar com dado real, e testar o cenário de falha de propósito, não só o caminho em que tudo dá certo. É o único jeito confiável de achar o que um teste em branco nunca mostra.
Perguntar, antes de assinar qualquer plataforma, como se sai dela. Exportação de dado em formato padrão, API documentada, contrato que não amarra o dado lá dentro.
Checar a LGPD antes de escalar, não depois. Se o app decide algo sobre uma pessoa, ou lida com dado sensível, tratar como alto risco desde o desenho, independente do tamanho da empresa.
Conferir sempre no resultado final. O PDF gerado, a nota emitida, a tela em produção, nunca só a mensagem de “salvo com sucesso” ou o código que parece certo.
A ferramenta certa depende do problema, do volume de dado e do que está em jogo se algo sair errado. A parte que não muda, seja o sistema feito em um fim de semana ou em seis meses, é que a tecnologia entra para organizar o que já existe, e quem continua respondendo pelo resultado é a empresa.
Vilmar Bressan é fundador da Inteligência para Crescer, consultoria que aplica duas décadas de gestão de processos, finanças e inteligência artificial a negócios locais. A casa já construiu com baixo código e com código próprio, para clientes e em produtos próprios, e carrega os riscos descritos aqui como experiência de campo, não como teoria.
Se sua empresa está decidindo entre construir, contratar pronto ou automatizar um processo, converse sobre o seu desafio.