Reescrever o MVP do zero ou evoluir o que existe? Como decidir sem jogar dinheiro fora

Você lançou seu MVP. Ele funciona, tem usuários, talvez até fature. E então alguém da equipe, ou um dev que você contratou para avaliar o produto, solta a frase: "isso aqui precisa ser reescrito do zero". De repente você está diante de uma decisão que pode custar meses e dezenas de milhares de reais, sem entender direito o que está em jogo.

Respira. Vamos por partes. Essa conversa aparece em quase todo produto que sobrevive à primeira fase, e a resposta certa quase nunca é a mais óbvia. Este artigo existe para você, fundador não técnico, sair da conversa com seu time de desenvolvimento sabendo exatamente o que perguntar e o que desconfiar.

Por que todo mundo quer reescrever o seu MVP

Primeiro, um insight de comportamento que explica muita coisa: desenvolvedores preferem escrever código novo a entender código dos outros. Ler um sistema existente é trabalho lento, cheio de decisões que parecem estranhas fora de contexto. Começar do zero dá sensação de controle e de progresso rápido.

Isso não torna o dev mal-intencionado. Torna a sugestão de reescrita suspeita por padrão. Quando alguém diz "é mais rápido refazer do que consertar", essa pessoa está comparando o custo real de entender o sistema atual com uma estimativa otimista do sistema novo. E estimativas de sistema novo são quase sempre otimistas, porque o código novo ainda não encontrou os problemas que o código velho já resolveu.

Seu MVP feio e remendado carrega meses de aprendizado embutido: o bug do pagamento que só acontecia no Pix, a regra de cancelamento que o cliente pediu, o caso do usuário que se cadastra duas vezes. A reescrita joga tudo isso fora e reaprende na base do erro em produção.

A pergunta certa não é "o código está ruim?"

Todo código de MVP está ruim em algum grau. Ele foi escrito para validar uma ideia rápido e barato, e cumpriu essa função. Julgar um MVP pela elegância do código é julgar um protótipo de papelão pelo acabamento.

A pergunta certa é: o código atual está impedindo o negócio de andar? Em termos práticos:

• Funcionalidades novas que antes levavam duas semanas agora levam dois meses?
• Cada mudança quebra algo que já funcionava?
• O sistema cai ou fica lento quando o volume de usuários cresce?
• Nenhum dev sério aceita dar manutenção no que existe?

Se você respondeu não para todas, a reescrita é vaidade técnica. Se respondeu sim para duas ou mais, aí a conversa fica séria, mas ainda não significa reescrever tudo.

As três opções reais (reescrever tudo é só uma delas)

Quando o produto trava, existem três caminhos, e eles têm custos muito diferentes.

1. Refatorar por partes, sem parar o produto

É o caminho padrão e o mais barato na maioria dos casos. O time melhora o sistema por dentro, um pedaço por vez, enquanto o produto continua no ar e evoluindo. O usuário não percebe nada. Não existe "grande lançamento da versão 2", existe um produto que vai ficando mais estável a cada mês.

Custo típico: 20% a 40% da capacidade do time dedicada a melhorias durante alguns meses, junto com o trabalho normal. Sem pausa nas funcionalidades novas.

2. Reescrever um módulo, manter o resto

Às vezes só uma parte do sistema virou gargalo: o checkout, o cadastro, o painel administrativo. Reescrever esse módulo isolado e conectar ao restante resolve 80% da dor com 20% do custo de uma reescrita total.

No Revo, nosso app de eventos com mais de 40 mil usuários, foi exatamente assim. O checkout foi reconstruído de forma isolada quando percebemos que ele era o ponto que mais influenciava receita. O resto do app continuou rodando. Hoje esse checkout converte a 90%, e nunca precisamos parar o produto para chegar lá.

3. Reescrever do zero

O caminho mais caro e mais arriscado. Faz sentido em poucos cenários legítimos:

• O MVP foi feito em no-code ou low-code e bateu no teto da ferramenta (limite de usuários, de integrações, de customização).
• A tecnologia escolhida está morta ou sem profissionais no mercado.
• O produto validado é tão diferente do MVP original que aproveitar o código atrapalha mais do que ajuda.
• Existe um problema estrutural de segurança ou de dados que não dá para corrigir por partes.

Fora desses casos, reescrever do zero costuma ser a decisão que quebra startups em fase inicial. E o motivo é o próximo tópico.

O custo escondido da reescrita: o produto para de evoluir

O orçamento da reescrita nunca é só o valor do desenvolvimento. Uma reescrita total de um MVP com algum volume de funcionalidades leva, de forma realista, de 3 a 8 meses e algo entre R$ 60 mil e R$ 250 mil dependendo da complexidade, do time e do que precisa ser migrado.

Mas o custo maior é invisível: durante a reescrita, o produto atual congela. Nada de funcionalidade nova, nada de responder rápido ao feedback dos usuários, nada de reagir ao concorrente. Para uma startup em validação, meses sem evoluir o produto podem custar a tração inteira. Você troca aprendizado de mercado por limpeza de código, e nessa fase aprendizado vale muito mais.

Tem ainda o risco clássico: a versão 2 chega atrasada, com menos funcionalidades que a versão 1, e com bugs novos que a versão 1 já não tinha. Esse padrão é tão comum na indústria que virou quase uma lei.

O roteiro para decidir: 5 perguntas antes de aprovar qualquer reescrita

Antes de assinar um orçamento de reescrita, faça este exercício. Isso você consegue fazer essa semana, sem gastar nada.

1. Peça exemplos concretos de bloqueio. "Me mostra três funcionalidades que ficaram mais caras ou impossíveis por causa do código atual." Se a resposta for genérica ("o código está bagunçado"), desconfie.
2. Pergunte pela opção intermediária. "O que dá para resolver refatorando por partes ou reescrevendo só o módulo problemático?" Quem descarta essa opção sem justificar está vendendo projeto, não solução.
3. Exija um plano de convivência. Como o produto atual continua no ar durante a reescrita? Quem corrige bugs nele? Como migram os dados dos usuários? Sem resposta clara para isso, o plano não existe.
4. Pergunte o que acontece com o aprendizado embutido. Como o time garante que as regras de negócio escondidas no código velho não se perdem? A resposta boa envolve mapear o comportamento atual antes de escrever a versão nova.
5. Faça a conta do congelamento. Quantos meses sem funcionalidade nova o seu negócio aguenta? Se a resposta for "poucos", a reescrita total provavelmente não cabe agora, mesmo que tecnicamente se justifique.

E se o MVP foi feito em no-code?

Caso especial que merece um parágrafo próprio, porque é a situação onde a reescrita mais se justifica. Se você validou sua ideia em Bubble, FlutterFlow ou similar, parabéns: a ferramenta cumpriu o papel dela, que era validar barato. Bater no teto do no-code não é fracasso, é sinal de que o produto merece uma fundação própria.

Ainda assim, a regra do módulo vale: às vezes dá para migrar só a parte crítica (o app do usuário final, por exemplo) e manter o painel interno no no-code por mais um ano. Migração total de uma vez só deve ser a exceção, não o reflexo.

Quando chegar a hora de decidir, converse com quem já fez essa conta

Na OCA, uma parte dos projetos que recebemos são exatamente esse cenário: MVP validado, produto travado, fundador sem saber se conserta ou refaz. Nossa primeira entrega nesses casos costuma ser um diagnóstico honesto, e com alguma frequência a resposta é "não reescreva, ainda não". Falamos isso porque operamos nosso próprio produto em produção e sabemos o que congelar a evolução custa. Time sênior tem menos apego a código novo e mais apego ao que faz o negócio andar.

Se você está diante dessa decisão agora, o próximo passo é simples: Tire seu MVP do papel com a OCA e traga o contexto do seu produto. Antes de qualquer orçamento, a gente te ajuda a responder a pergunta certa: o que, exatamente, está impedindo seu negócio de crescer?

E a ação gratuita desta semana: liste as três últimas funcionalidades que você pediu ao time e quanto tempo cada uma levou. Se o tempo está crescendo a cada pedido, você tem um dado real para a conversa. Se não está, guarde o dinheiro da reescrita. Seu produto não precisa ser perfeito por dentro. Precisa continuar evoluindo.