Construtor de apps no-code com IA: quando ficar e quando sair

Um construtor de apps no-code com IA como Lovable, Bolt ou Base44 é um bom lugar para ficar enquanto o seu app é um protótipo, uma ferramenta interna ou um produto pequeno com regras simples. Você deve sair, ou pelo menos levar o código para fora, quando precisar de controle sobre regras de dados, pagamentos, performance, hospedagem ou sobre quem pode mudar o código.

Sou um engenheiro brasileiro e não tenho nenhum interesse em qual ferramenta você usa. O que segue é como eu decidiria, com base na minha experiência como engenheiro, incluindo a migração de uma plataforma em produção. Trate o código gerado por IA como um primeiro rascunho: corrija o que existe antes de pensar em uma reescrita.

O que um construtor de apps no-code com IA faz bem?

Essas ferramentas são fortes em levar uma ideia a algo clicável em horas. Elas geram telas, formulários, tabelas básicas de banco de dados e fluxos simples de login rapidamente. Para fundadores validando demanda, essa velocidade vale muito.

Elas funcionam bem para:

• Protótipos e demos para investidores ou primeiros clientes.
• Dashboards internos usados por um punhado de pessoas de confiança.
• Landing pages com um cadastro simples ou lista de espera.
• Ferramentas pequenas em que um erro custa pouco e os dados não são sensíveis.

Onde elas costumam ser mais fracas é nas partes que exigem julgamento: quem pode ler qual linha, quais chaves são seguras no navegador, como um pagamento é confirmado e o que acontece com tráfego real. São essas as áreas em que as ferramentas costumam errar.

Quando ficar no construtor é a melhor escolha?

Ficar é a melhor escolha mais vezes do que os engenheiros gostam de admitir. Uma migração custa tempo, e tempo gasto migrando é tempo que não é gasto aprendendo com os usuários.

Eu ficaria quando:

• Você ainda não provou que alguém quer o produto.
• O app guarda poucos dados pessoais e não recebe pagamentos.
• Uma pessoa não técnica edita o app e esse fluxo funciona para ela.
• A plataforma cuida da hospedagem e você não tem ninguém que manteria servidores.
• As quatro checagens principais passam: suas regras de dados estão corretas, não há chaves secretas no navegador, os pagamentos são confirmados no servidor e existem backups.

Lembre-se da divisão de responsabilidade compartilhada. O construtor protege a infraestrutura e as contas dele. Você é responsável por quem pode ler quais dados, pelas chaves no navegador, pela confirmação de pagamento e pelos backups. Essa responsabilidade não vai embora se você sair, e não desaparece se você ficar.

Um exemplo público: em julho de 2025, pesquisadores da Wiz descobriram que o Base44, que pertence à Wix, permitia que um atacante se cadastrasse em apps que deveriam ser privados usando apenas o ID do app. Foi corrigido em menos de um dia. Isso mostra o lado da plataforma sendo tratado rapidamente. Também mostra por que você deve saber o que o seu próprio app expõe.

Quais sinais mostram que você já superou o construtor?

Estes são os sinais que eu procuro. Um sozinho raramente basta. Dois ou três juntos normalmente significam que é hora de planejar uma migração.

• Usuários reais e dinheiro real. Você recebe pagamentos ou guarda dados que as pessoas ficariam chateadas de ver vazados.
• Regras que você não consegue expressar. Você precisa de uma lógica de acesso que o construtor continua errando, como row level security no Supabase. Apps construídos com Lovable têm mostrado um padrão de regras de RLS fracas.
• Loops de correção. Cada prompt para corrigir um bug quebra outra funcionalidade.
• Lento sob tráfego. Páginas ou consultas ficam lentas quando mais do que algumas pessoas usam o app.
• Engenheiros não conseguem trabalhar nele. Um desenvolvedor que você contrata quer pull requests normais, code review, staging e testes.
• Perguntas de compliance ou de clientes. Compradores perguntam onde os dados ficam e quem tem acesso a eles.

É tentador pedir para o construtor com IA corrigir isso, mas regras de dados, chaves e fluxos de pagamento são exatamente o que as ferramentas costumam errar. Um scanner genérico também deixa passar lógica de negócio como webhooks do Stripe e pedidos duplicados, então uma revisão humana desses fluxos faz diferença.

O que é preciso para levar o código para o GitHub e para a sua própria hospedagem?

Código construído no Lovable pode ser levado para o GitHub e para a sua própria hospedagem. Os passos gerais são parecidos para outros construtores, mas as opções de exportação variam, então confira o que o seu suporta.

1. Conecte ou exporte o repositório. Coloque o código completo no GitHub, em uma conta que pertença à sua empresa.
2. Faça um inventário de tudo o que está fora do código. Liste o banco de dados, as configurações de autenticação, os buckets de armazenamento, as variáveis de ambiente, o provedor de email e os webhooks de terceiros.
3. Troque os segredos. Considere exposta qualquer chave que tenha passado pelo navegador ou pelo histórico do chat, e substitua.
4. Configure a hospedagem e um pipeline. Faça deploy em um host que você controla, com ambientes separados de staging e produção.
5. Revise as regras de dados. Teste as políticas de acesso tentando ler os dados de outros usuários.
6. Verifique os pagamentos. Confirme pedidos a partir de eventos assinados no servidor, não a partir do redirecionamento do navegador.
7. Faça backup e teste uma restauração. Um backup que você nunca restaurou é um palpite.
8. Faça a virada. Troque o DNS ou o tráfego quando o staging se comportar como produção.

O banco de dados costuma ser a parte mais difícil. Se você usa Supabase, pode mantê-lo como backend e migrar só o frontend, o que reduz muito o risco.

Quanto custa sair do construtor em tempo e risco?

Não vou inventar um preço, porque depende do tamanho do app, do volume de dados e de quão bagunçado está o código gerado. O que posso dizer é como o custo costuma se comportar.

• A maior parte do risco é encontrada por algumas checagens focadas, não por uma auditoria completa.
• O custo de corrigir cresce depois que chegam usuários reais e pagamentos, porque toda mudança passa a mexer em dados reais.
• Uma reescrita custa mais do que corrigir as partes de maior risco do código existente, então comece pelas correções.

Liderei a migração completa de uma plataforma de candidatura automática a vagas, em produção, de uma stack legada para uma nova enquanto os usuários continuavam usando. A lição que tirei: o código raramente é a parte difícil. A parte difícil é mover os dados, manter o comportamento idêntico e ter um caminho de volta se algo der errado. Planeje rodar os dois em paralelo, teste com dados realistas e mantenha o sistema antigo até o novo se provar. Não posso prometer um prazo fixo para o seu app, já que isso depende do que você encontrar no inventário.

Essas são as minhas regras práticas, não números medidos.

Dá para migrar parte do app e manter o resto no construtor?

Sim, e muitas vezes é o meio-termo sensato. Você não precisa escolher entre tudo ou nada.

Divisões comuns que eu consideraria:

• Migrar os pagamentos primeiro. Coloque o tratamento do Stripe em um servidor pequeno que você controla e deixe as telas no construtor.
• Manter o Supabase, migrar o frontend. Seus dados ficam onde estão enquanto a interface passa a viver no GitHub e na sua hospedagem.
• Tirar os jobs pesados. Rode tarefas lentas ou agendadas em um serviço separado.
• Manter o painel de administração. Ferramentas internas podem ficar no construtor muito depois de o app público ter migrado.

O preço é a complexidade. Dois sistemas significam dois lugares para monitorar e proteger. Anote quem é dono de cada parte, para que nada fique no meio do caminho.

Quer uma segunda opinião?

Se você está decidindo entre ficar ou migrar, mande um email para me@filipeeduardo.dev com o link e uma descrição curta, e eu te digo o que checaria primeiro.