Vinicius Monteiro Dias
Resumo rápido. A hora de sair do no-code chega quando a ferramenta passa a limitar mais do que ajuda: automação que esbarra em cota, dado duplicado entre telas, permissão que só existe no "tudo ou nada". A saída não precisa ser uma reescrita completa de uma vez. Dá para migrar processo por processo, rodando o sistema novo em paralelo com o antigo até ele provar que funciona.
Os quatro sinais que ninguém percebe a tempo
No-code resolve bem o primeiro ano de uma operação. O problema aparece devagar, então a maioria das equipes só nota quando já está incomodando todo mundo.
Um aviso antes dos números abaixo: eles vêm de documentação pública e comparativos de terceiros, não das páginas oficiais de pricing das ferramentas, e mudam com frequência. Trate cada valor como ordem de grandeza, não como cotação fechada, e confira o site oficial antes de decidir qualquer coisa.
1. Automação que para sem aviso
Zapier cobra por tarefa executada, não por assento. No plano gratuito, um fluxo de dois passos consome a cota rápido. No plano intermediário, o volume sobe, mas o modelo continua o mesmo: quanto mais a operação cresce, mais caro fica manter as mesmas automações rodando. Bubble segue uma lógica parecida, só que pior de prever: cobra por "unidade de trabalho" (workload), e uma busca no banco sem filtro, um workflow em loop ou um plugin mal configurado consomem workload de um jeito que ninguém vê chegando. Workflows no Bubble também costumam esbarrar num limite de tempo de execução, algo na casa de cinco minutos segundo a documentação da ferramenta, e processo mais pesado simplesmente trava no meio.
Quando a automação para "sozinha" no fim do mês, geralmente não é bug. É cota.
2. Dado duplicado e registro que não bate
Airtable soma registros de todas as tabelas de uma base para calcular o limite do plano contratado. Duas tabelas de cerca de 25 mil linhas cada uma já se aproximam de um teto comum de 50 mil registros nos planos intermediários. Antes mesmo de bater no teto, a performance costuma cair de forma perceptível na faixa dos 20 mil registros, o que significa que o problema de lentidão chega antes do limite contratual aparecer na fatura.
Notion tem um teto mais alto, algo em torno de 250 mil linhas por database segundo comparativos públicos, mas junto vêm outros limites que forçam gambiarra: por volta de 500 propriedades, cerca de 2,5MB por página somando todos os campos, algo como 25 visualizações por database e um limite próximo de mil itens em relações entre tabelas. Passado esse ponto, o time começa a quebrar uma base grande em várias bases menores linkadas, e é exatamente aí que o dado duplicado começa a aparecer, porque ninguém sincroniza manualmente com 100% de consistência.
3. Permissão que só existe no "tudo ou nada"
Airtable não tem controle nativo por linha ou registro. A permissão funciona no nível da base ou do workspace inteiro: ou a pessoa vê tudo daquela base, ou não vê nada. Para restringir por registro, a saída do mercado é colocar uma ferramenta por cima, como Softr, só para tapar esse buraco.
Notion resolveu parcialmente com permissão por página dentro de uma database, mas, segundo a estrutura de planos atual, esse recurso costuma ficar restrito aos planos Business e Enterprise. Quem está no plano Free ou Plus, em geral, simplesmente não tem essa opção.
Isso vira problema real assim que a operação tem informação sensível: dado financeiro, contrato de cliente, dado de PJ. Sem permissão granular, a saída de muita empresa é confiar no "ninguém vai mexer onde não deve", o que não é controle, é sorte.
4. Custo que escala sem avisar
O padrão dos quatro pontos acima é o mesmo: no-code cobra pelo uso, não pelo time. Mais automação, mais registro, mais gente acessando, custo sobe, e nem sempre de forma proporcional ou previsível. Isso é ótimo enquanto a operação é pequena e o custo é baixo. Vira problema quando a operação cresce e a conta cresce mais rápido que o orçamento.
O custo de ficar também está subindo
Vale desmontar uma ideia comum: "não migrar agora" não é uma decisão neutra e sem custo. Por volta do início de 2026, segundo registros de comparativos de terceiros, a Airtable teria reduzido o limite do plano gratuito de perto de 1.200 para cerca de 1.000 registros por base, um movimento que a própria empresa pode ajustar de novo a qualquer momento. Os limites de chamada de API também apareceram mais apertados nessas fontes: conta gratuita na casa de mil chamadas por mês, plano intermediário em torno de cem mil chamadas por mês e teto de cerca de cinco requisições por segundo. Uma automação que depende de API pode simplesmente parar de funcionar da noite para o dia se estourar essa cota, sem nenhuma mudança do lado da empresa.
O padrão é: fornecedor de no-code aperta o cinto do plano de entrada com o tempo, empurrando o cliente para planos mais caros antes mesmo de ele decidir migrar para algo próprio. Ficar parado também tem preço, só que ele aparece como upgrade forçado em vez de projeto de migração.
Como sair sem parar a operação
A arquitetura de software tem um nome para isso: strangler fig, um padrão descrito por Martin Fowler e documentado oficialmente pela AWS e pela Microsoft. A ideia central, em linguagem de negócio, é simples: não existe um dia em que a empresa "troca tudo". Existe um processo de cada vez sendo movido para o sistema novo, enquanto o resto continua rodando onde sempre rodou.
Na prática, isso significa:
- Escolher o processo mais doloroso primeiro. Não o mais fácil, o mais doloroso. Se contas a pagar é o que mais trava a operação hoje, é ali que a migração começa, isolada do resto. Gera resultado visível rápido e mostra que o caminho funciona antes de expandir.
- Rodar em paralelo até confiar. O sistema novo entra em produção enquanto a ferramenta antiga continua ativa para aquele processo. Essa fase, às vezes chamada de shadow run, é onde a equipe aprende a confiar no sistema novo sem apostar a operação inteira nele de uma vez.
- Ter uma camada de tradução entre os dois sistemas. Enquanto os dois coexistem, alguma coisa precisa garantir que uma mudança feita no sistema novo não quebre o que ainda depende do antigo, e vice-versa. Isso pode ser tão simples quanto uma rotina que sincroniza os dados uma vez por hora.
- Tratar inconsistência temporária como esperada, não como falha. Durante a transição, é normal que os dois sistemas fiquem levemente fora de sincronia por minutos ou horas. O erro é tentar corrigir isso na mão toda vez; o certo é definir qual sistema é a fonte de verdade e deixar a sincronização seguir esse sentido.
- Só desligar a ferramenta antiga depois que o novo sistema prova valor naquele processo específico, não antes.
Essa lógica de "um processo por vez" já aparece em consultorias de gestão brasileiras recomendando exatamente isso para quem está saindo de planilha ou Airtable: identificar o gargalo mais manual, migrar isolado, mostrar resultado, só então expandir. É o mesmo princípio do strangler fig, só que aplicado a processo de negócio em vez de código.
Comparativo rápido (ilustrativo, confira sempre o site oficial antes de decidir)
Os números de pricing de ferramentas no-code mudam com frequência, então trate o quadro abaixo como ordem de grandeza, não como cotação fechada.
| Ferramenta | Limite típico | Permissão granular | Modelo de cobrança |
|---|---|---|---|
| Airtable | Dezenas de milhares de registros por base, cumulativo entre tabelas | Não nativa (tudo ou nada por base/workspace) | Por assento, plano define teto de registros e chamadas de API |
| Notion | Até centenas de milhares de linhas, com limite de propriedades e views | Só nos planos superiores (Business/Enterprise) | Por assento |
| Zapier | Definido por cota de tarefas executadas por mês | Não é o foco da ferramenta | Por tarefa executada, não por usuário |
| Bubble | Sem teto fixo de usuários, mas workflow tem timeout de 5 minutos | Depende de construção manual na aplicação | Por unidade de workload, consumo imprevisível |
Checklist de prontidão
Antes de decidir migrar, confira quantos desses sinais já apareceram na sua operação:
- Alguém já lançou o mesmo pedido, contrato ou registro duas vezes porque não ficou claro onde estava a versão certa.
- Um relatório importante depende de uma pessoa específica exportar e cruzar dados na mão.
- Uma automação parou de funcionar sem ninguém mexer em nada, e a explicação foi "cota".
- Cliente ou equipe interna pediu uma função (login social, mais de um meio de pagamento, acompanhamento em tempo real, permissão por usuário) que a ferramenta atual nunca vai priorizar.
- O custo mensal da ferramenta subiu mais rápido do que o número de pessoas usando ela.
Duas ou três marcadas já é sinal de atenção. Quatro ou cinco, a conversa sobre sistema próprio deixou de ser prematura.
Não é escolha entre planilha e sistema caro
A decisão real não é "continuar como está" contra "gastar uma fortuna reescrevendo tudo". É escolher o processo que mais dói hoje e migrar só ele primeiro, com o resto da operação intocado enquanto isso. Detalhamos essa conta de custo com mais profundidade no post sobre quanto custa um sistema sob medida.
Se a sua operação já bateu em dois ou três dos sinais deste checklist, vale uma conversa antes de assinar o próximo upgrade de plano. A Impulse Works trabalha exatamente com esse tipo de migração fatiada: identificar o processo mais travado, construir o sistema novo em paralelo, e só desligar a ferramenta antiga quando o novo já provou que aguenta.
