Uma empresa já investiu tempo em um sistema gerado com IA. Há telas, cadastros e algumas integrações, mas a equipe não confia em colocar a operação inteira ali. A decisão não precisa ser entre continuar improvisando ou jogar tudo fora. Primeiro é necessário descobrir o estado real do produto.
Profissionalizar um protótipo começa por inventariar ativos, validar comportamentos e priorizar riscos. A origem do código é uma informação do contexto, não um diagnóstico. O plano deve preservar o que funciona e corrigir o que impede uma operação confiável.
1. Faça um inventário antes de alterar
Liste repositório, ambientes, banco, autenticação, arquivos, domínios, funções e serviços externos. Identifique titulares das contas e acessos disponíveis. Não inicie uma migração supondo que tudo está dentro da pasta de código.
Registre como o sistema é construído e publicado. Quais comandos, versões e variáveis são necessários? Quais tarefas rodam fora da aplicação? Existe uma função na plataforma que não foi exportada? Esse mapa evita descobrir dependências apenas depois de desligar a origem.
Faça cópias recuperáveis e registre o estado inicial antes de intervenções. A recuperação deve considerar dados e configuração, não apenas o código. Um backup sem teste e sem conhecimento de conteúdo pode oferecer uma segurança ilusória.
2. Transforme o produto em jornadas verificáveis
Escolha processos reais: cadastrar um cliente, abrir um projeto, aprovar uma proposta e concluir uma cobrança. Para cada jornada, descreva entrada, permissão, efeito e resultado esperado. Use dados de teste que incluam exceções.
Não aceite “a tela abre” como conclusão. Uma proposta pode abrir e calcular incorretamente; uma cobrança pode ser enviada duas vezes; um arquivo pode estar público. A avaliação deve acompanhar a tarefa completa até a persistência e o efeito externo.
Priorize a experiência que a empresa pretende usar agora. Validar dezenas de módulos sem foco pode consumir esforço sem reduzir o principal risco. Um produto menor e confiável pode ser uma base melhor que um menu extenso de funções incertas.
3. Classifique achados por impacto
| Classe | Exemplo | Tratamento inicial |
|---|---|---|
| Exposição | Acesso a dados de outra empresa | Conter e corrigir com prioridade |
| Integridade | Duplicação de lançamento | Proteger o efeito e reconciliar |
| Operação | Tarefa sem recuperação | Criar estado e procedimento |
| Manutenção | Regras duplicadas | Consolidar com testes |
| Experiência | Erro sem orientação | Melhorar recuperação do usuário |
A prioridade depende de impacto e possibilidade de ocorrência. Um detalhe visual pode ser urgente se impede a tarefa principal; um módulo pouco usado pode conter uma falha grave de acesso. Evite uma classificação baseada apenas na aparência.
4. Revise limites de confiança
Mapeie tudo que chega do navegador, de arquivos e de serviços externos. Essas entradas precisam de validação e autorização. Verifique se o servidor confia indevidamente em preço, organização ou perfil enviados pelo cliente.
O OWASP ASVS é uma referência para estruturar verificações de aplicação. Use requisitos selecionados de forma proporcional e registre evidências. Um relatório genérico sem reproduzir os caminhos do produto não oferece a mesma utilidade que testes concretos.
Inclua tarefas administrativas e automações. Um bot ou rotina de fundo pode possuir acesso amplo e produzir efeitos em nome de usuários. O controle não termina nas rotas visitadas por uma pessoa no navegador.
5. Escolha entre corrigir, reorganizar e substituir
Corrija pontualmente quando o problema é localizado e o comportamento está compreendido. Reorganize quando regras espalhadas dificultam manutenção, mas a base é aproveitável. Substitua um componente quando o custo de torná-lo confiável supera uma alternativa bem delimitada.
Não confunda reescrita com melhoria garantida. Um novo código sem testes pode repetir os mesmos erros e perder regras que só existiam no sistema antigo. Antes de substituir, documente comportamentos necessários e critérios de equivalência.
Também evite acumular correções sobre uma estrutura que ninguém consegue explicar. A decisão deve equilibrar prazo, risco e continuidade. Registre por que determinada parte foi preservada ou descartada para que o plano não pareça arbitrário.
6. Crie uma linha de testes antes das mudanças maiores
Monte cenários de regressão para regras críticas. Eles permitem comparar versões e reduzir a chance de uma correção quebrar outro fluxo. Teste autorização, cálculos, transições, repetição e falhas de integração conforme o produto.
Os testes não precisam espelhar cada função. Devem proteger comportamentos que importam para o negócio. Uma suíte enorme de verificações superficiais pode ser menos útil que um conjunto menor que detecta os incidentes mais relevantes.
O roteiro de CI/CD ajuda a levar essas evidências para o processo de entrega. A verificação deve acompanhar a versão realmente publicada, não apenas o ambiente de um desenvolvedor.
7. Planeje a migração como um processo próprio
Se houver mudança de hospedagem ou serviços, transfira código, dados, usuários e arquivos pelos mecanismos adequados. A documentação de propriedade e implantação do Lovable descreve possibilidades desse ecossistema, mas cada projeto precisa de um inventário concreto.
Valide o destino antes do corte. Teste autenticação, consultas, uploads, tarefas e integrações. Defina como lidar com gravações que continuam ocorrendo na origem durante a transferência. Sem isso, o destino pode começar incompleto mesmo após uma importação aparentemente bem-sucedida.
Um plano de retorno deve considerar novas gravações. Voltar o endereço para a origem não transfere automaticamente os dados criados no destino. A recuperação precisa ser desenhada para o momento da mudança.
8. Exemplo hipotético de evolução por etapas
Um portal possui cadastro e documentos úteis, mas aprovação e cobrança são frágeis. A primeira etapa protege acesso e credenciais. A segunda consolida regras e adiciona testes. A terceira publica o fluxo de aprovação com confirmação e histórico. A cobrança só entra depois de validar repetição e falhas.
A empresa passa a usar um conjunto confiável enquanto o restante evolui. O projeto anterior não é tratado como lixo, nem como produto pronto. Ele é uma base cujo valor foi medido e cujo risco passou a ser controlado.
9. Documente a entrega para outra equipe
Inclua instalação, variáveis por finalidade, migrações, publicação, recuperação e contas sob responsabilidade da empresa. Não registre segredos em documentos abertos. Explique como obtê-los e administrá-los nos locais protegidos.
Documentação deve permitir executar tarefas, não apenas listar tecnologias. Uma pessoa autorizada precisa conseguir publicar uma versão e investigar um incidente sem depender de memória informal. Essa capacidade é parte importante da profissionalização.
Critérios de saída para considerar a evolução concluída
Defina uma lista de jornadas aprovadas e associe cada uma à versão testada. Registre falhas conhecidas, limitações e procedimentos de contingência. Concluir não significa alegar ausência de qualquer defeito; significa atender critérios acordados e tornar o risco remanescente explícito.
A publicação deve ter identificação de versão, verificação de saúde e teste funcional. Confirme que o ambiente usa o banco, os arquivos e os provedores corretos. Um projeto pode passar na homologação e falhar em produção por configuração, mesmo quando o código é igual.
Entregue acessos e instruções a pessoas autorizadas e valide uma tarefa de continuidade. Por exemplo, reconstruir o ambiente de teste ou restaurar uma amostra em local isolado. Esse exercício revela dependências que um documento descritivo pode ter omitido.
Por fim, estabeleça um período e um canal para observar o uso inicial conforme o contrato. Novos usuários podem revelar exceções que não apareceram nos testes. O fluxo de triagem deve distinguir defeito, configuração e mudança de escopo para que a evolução continue organizada.
Checklist de diagnóstico
- Inventariar todos os ativos e dependências.
- Preservar um estado inicial recuperável.
- Definir jornadas e critérios de aceite.
- Classificar risco por impacto real.
- Revisar entradas e operações privilegiadas.
- Criar testes antes de mudanças maiores.
- Validar destino e corte em qualquer migração.
- Entregar procedimentos de continuidade.
Checklist para usar com sua equipe
Baixe o checklist editável em CSV e registre responsáveis, verificações e observações da implantação.
Perguntas frequentes
Preciso abandonar a plataforma imediatamente?
Não necessariamente. Primeiro avalie riscos, dependências e alternativas. Uma mudança apressada pode criar outros problemas.
É possível aproveitar a interface existente?
Pode ser. A decisão depende da qualidade, do acoplamento e da aderência às jornadas, não apenas da aparência.
Uma auditoria deve terminar com um orçamento de reescrita?
Não obrigatoriamente. Ela deve apresentar achados e opções justificadas, inclusive correções incrementais quando adequadas.
Próximo passo
Fale com a A2CR para avaliar o que preservar e o que corrigir antes de ampliar o investimento.
Autoria: Agência A2CR. Revisão: 10 de novembro de 2026. Roteiro técnico e exemplo hipotético elaborados pela A2CR.
