7 min · publicado em 10 de jul. de 2026
Quando corrigir e quando reconstruir um MVP
Critérios para decidir sem apego ao código atual e sem transformar uma reescrita em resposta automática.
Por Leonardo Soledade · consultor de produto e software
Reescrever não é sinônimo de melhorar
Uma nova base remove problemas conhecidos, mas também descarta comportamento validado e cria uma nova rodada de bugs. A decisão deve comparar custo, risco e velocidade para o próximo objetivo do negócio.
Quando preservar a base
Se os fluxos principais funcionam, os dados têm estrutura compreensível e os problemas estão concentrados em módulos identificáveis, uma correção progressiva costuma entregar valor mais cedo.
- Há testes ou uma forma confiável de validar o comportamento
- Dependências ainda recebem manutenção
- O modelo de dados representa o negócio
- Os maiores problemas podem ser isolados
Sinais de reconstrução
Reconstrução ganha força quando não existe controle de acesso confiável, alterações simples quebram áreas distantes, a tecnologia bloqueia requisitos essenciais ou não há caminho seguro para migrar dados e ambiente.
Faça a decisão produzir um plano
A conclusão de uma auditoria não deve ser apenas ‘está ruim’. Ela precisa indicar quais partes ficam, quais mudam, como validar a transição e qual risco é reduzido em cada etapa.