Software rewrite: a pergunta errada que cai no colo do fundador não-técnico no pior momento

Um guia de campo para fundadores que estão sendo convencidos a financiar uma reescrita de software: o que a pergunta realmente significa, por que quase sempre dá errado, e as quatro perguntas que você deveria fazer antes de assinar qualquer coisa.

Camila era CEO havia dezenove meses quando o dev líder entrou numa 1:1 e disse a frase que todo fundador não-técnico ouve uma hora: “Precisamos reescrever isso.” O produto tinha clientes reais, receita mensal, e um cheque de investidor que havia caído em fevereiro. O codebase tinha dezoito meses, foi construído rápido durante o pre-seed, e mostrava cada uma das digitais dos quatro contractors que passaram por ele. O dev queria seis meses e uma folha em branco. O investidor esperava novas features. Camila não tinha como saber se aquilo era uma decisão séria de engenharia ou a alergia de um dev júnior a código herdado.

Um software rewrite é a decisão de jogar fora um codebase existente e construir uma substituição do zero, normalmente porque o time acredita que o sistema atual não consegue mais evoluir na velocidade que o negócio precisa. Essa é a definição de manual. A definição honesta é mais áspera: rewrite é o que é proposto quando alguém do time perdeu a fé no código e já não consegue separar o problema técnico do problema emocional.

Para um fundador não-técnico, a pergunta do rewrite quase nunca é a pergunta que deveria ser respondida. São três perguntas empilhadas, e responder a errada é como uma empresa em estágio inicial queima um ano de runway reconstruindo o que ela já tinha.

Por que “devemos reescrever?” é a pergunta errada

O enquadramento que o dev te entrega é binário. Mantém o código antigo, ou começa do zero. Esse enquadramento é o que faz o rewrite ser aprovado, porque as duas respostas parecem decisões e uma delas soa como progresso.

Na prática, nenhuma das duas é o que o negócio precisa. O negócio precisa saber o que está te machucando. O codebase é uma das possíveis causas. Em geral são quatro: o sistema genuinamente não consegue fazer o que o cliente precisa (arquitetura); o time não consegue entregar com segurança (operacional); os engenheiros não querem mais trabalhar no código (cultural); ou o fundador não consegue enxergar o que está acontecendo (visibilidade). Cada uma pede uma intervenção diferente, e só uma delas é um rewrite.

Se você aceita o binário, já perdeu a conversa. A pergunta não é “a gente mantém ou começa do zero.” A pergunta é: qual resultado específico de negócio o código atual está impedindo, e qual a menor mudança que resolve isso?

Os três problemas escondidos dentro da pergunta do rewrite

Quando um dev diz “precisamos reescrever isso”, quase sempre está misturando três problemas distintos. Separe-os antes de decidir qualquer coisa.

O problema de negócio

Comece aqui. Antes de qualquer conversa sobre código, nomeie o resultado de negócio que o sistema atual está tornando impossível. É entregar a próxima feature sem quebrar a anterior? É a latência que está custando um cliente flagship? É lançar um novo tier de preço? É um audit de segurança que você precisa passar para fechar um enterprise? É nenhum desses, e o problema real é que o dev está entediado?

A gente já viu fundadores financiarem rewrites de seis meses porque a velocidade de entrega tinha caído, só para descobrir seis meses depois que a entrega seguia lenta no novo codebase também. O problema original era um ambiente de staging que não existia e um processo de deploy não documentado. Nenhum dos dois exigia rewrite.

Se você não consegue terminar a frase “se a gente fizer esse rewrite, a empresa vai conseguir fazer X até a data Y e Z vai ser mensuravelmente diferente”, você não tem um problema de negócio. Você tem uma preferência de engenharia vestida de problema de negócio.

A hipótese técnica

Depois que o problema de negócio está nomeado, a próxima pergunta é: qual mudança técnica de fato resolve isso? Um rewrite é uma opção. Raramente é a mais barata. Quase sempre é a mais lenta. E carrega um risco específico que mudanças incrementais não carregam: o novo código tem que chegar à paridade de features com o velho antes de alguém poder usá-lo. Esse trabalho é invisível para clientes e investidores. Seis meses construindo coisas que já existem é uma das formas mais caras que um roadmap de startup pode ter.

Para a maior parte dos codebases em estágio inicial, as hipóteses mais baratas são: refactors direcionados em dois ou três módulos específicos; um novo serviço que cuida do pedaço quebrado enquanto o sistema antigo segue rodando; um rewrite de uma única camada (camada de acesso a dados, camada de auth) em vez do stack inteiro; ou consertar o deploy, o monitoramento e o setup de testes para que o código existente fique mais seguro de mexer. Quase nenhum fundador escuta essas opções porque o dev que propôs o rewrite já decidiu a resposta.

A aposta falsificável

O terceiro problema é o que quase nunca é articulado, e é o que separa decisões de engenharia reais das wishful. Toda proposta de rewrite é uma aposta. Apostas têm uma condição de falsificação: uma forma de saber, antes de começar, o que significaria que a aposta falhou.

Qual é a métrica que diz que esse rewrite funcionou? É frequência de deploy? Taxa de bugs por release? Tempo de onboarding de um novo engenheiro? Tempo de entregar uma feature que toca três módulos? Latência visível ao cliente? Seja qual for, tem que ser mensurável hoje, mensurável no sistema reescrito, e confiável a partir do assento do fundador, sem precisar perguntar ao dev. Se a aposta é “você vai se sentir melhor com o código”, você está financiando terapia, não engenharia. É a mesma lógica que usamos para definir o que um MVP de fato é: sem uma condição de falsificação, você tem um projeto, não uma aposta.

A regra de Joel Spolsky, 25 anos depois

Em 2000, Joel Spolsky escreveu o que ainda é o ensaio mais citado sobre o tema, Things You Should Never Do, Part I. Tese dele: reescrever do zero é o pior erro estratégico que uma empresa de software pode cometer. A Netscape perdeu a guerra dos browsers para a Microsoft porque passou três anos reescrevendo o Communicator enquanto o IE entregava. A frase que todo fundador deveria guardar do texto: “você está jogando fora a sua liderança de mercado.”

Vinte e cinco anos depois, a regra continua valendo para o caso que Spolsky estava protegendo: um produto em produção, com clientes reais, modelo de negócio funcionando, e um codebase que foi temperado por anos de edge cases. Não reescreva isso. Refatore.

O que mudou é a situação que Spolsky não estava endereçando. Ele estava escrevendo sobre a Netscape. O codebase que entra na porta da Pixel Breeders em 2026 é mais frequentemente um MVP de dezoito meses, construído por dois contractors e um stack no-code, que nunca foi engenheirado para durar. Não é um sistema testado em batalha. É um protótipo que sobreviveu ao contato com clientes, e os padrões que Spolsky estava defendendo não se aplicam todos.

Para esse codebase, a pergunta muda. Não é “devemos reescrever a Netscape.” É “o protótipo achou product-market fit antes da engenharia conseguir alcançar. E agora?” Essa pergunta tem outra resposta, e geralmente envolve reconstruir pedaços do sistema em paralelo enquanto o original continua rodando. Não é um rewrite completo. Não é um refactor. É algo no meio, com a mesma disciplina de falsificação de uma aposta de verdade.

Cinco perguntas para fazer antes de financiar um rewrite

Quando a proposta de rewrite chegar na sua mesa, passe por essas cinco em ordem. A maior parte dos rewrites cai nas perguntas 1, 2 ou 3.

1. Qual é a perda de negócio concreta que esse codebase está criando? Force um número ou uma data. Receita perdida, clientes não conquistados, um deal em risco, um deadline regulatório. “A gente não consegue se mexer rápido” não é resposta. “A Acme se recusou a renovar porque o endpoint de export dá timeout em arquivos acima de 50MB, e isso é R$ 900K de ARR” é resposta.

2. O dev consegue nomear a única mudança que resolveria 80% da perda? Peça que ele descreva a menor intervenção que endereça o problema nomeado. Se ele consegue dizer em um parágrafo, o rewrite provavelmente é a resposta errada e o que você deveria financiar é essa mudança. Se ele não consegue, esse é o seu sinal: o rewrite está sendo proposto como default, não como decisão.

3. Quem está recomendando o rewrite, e há quanto tempo está com o código? Devs que herdam um codebase chegam no momento “a gente devia reescrever isso” depois de uns três meses. É um padrão psicológico conhecido, não necessariamente técnico. Engenheiros sêniores que conviveram com um codebase por dois anos raramente propõem rewrites. Eles propõem refactors direcionados. Se o rewrite está sendo recomendado por alguém que entrou há seis semanas e só mexeu em um módulo, pondere a recomendação na proporção certa.

4. Isso é uma única data de entrega, ou um sistema paralelo que precisa convergir com produção? A resposta honesta quase sempre é a segunda. Rewrites que rodam como “vamos parar de construir features por seis meses e depois trocar” têm uma taxa de sucesso de ~10% pela nossa experiência. Rewrites que rodam como “vamos construir a coisa nova ao lado da antiga, migrar uma feature por vez, e desligar a antiga quando a migração estiver completa” chegam perto de 60%. O primeiro plano é uma coisa que engenheiros falam. O segundo é uma coisa que engenheiros entregam.

5. Como é o “pronto”, e ele é mensurável a partir do assento do fundador? Pronto não é “o código novo está com paridade de features.” Pronto é “a gente entrega a feature X em N dias em vez de M dias, e o cliente Y está usando o novo sistema em produção com a métrica Z.” Se o dev não consegue definir pronto de uma forma que um fundador não-técnico consiga verificar, o rewrite não tem condição de término. Um projeto sem condição de término não termina. Ele contrata mais devs.

Quando um rewrite de fato é a resposta certa

Pode ser. Quatro padrões específicos valem o investimento.

O primeiro é o MVP vibe-coded que encontrou product-market fit. A gente vê todo mês. Um fundador entregou alguma coisa em oito semanas usando um backend hospedado, três APIs de SaaS, e um punhado de features assistidas por LLM que ele não entende completamente. Funciona. Cliente paga. E cada feature nova quebra outra coisa, porque o sistema nunca foi desenhado para fazer o que agora precisa fazer. Nesse caso, o “rewrite” se parece mais com a primeira construção propriamente dita. A regra do Spolsky não se aplica porque não existe engenharia funcionando para jogar fora; existe um protótipo que agora precisa ser engenheirado. O framework que usamos com fundadores não-técnicos nessa exata decisão trata isso como a transição natural de “o que a gente construiu para aprender” para “o que a gente constrói para escalar.”

O segundo é a mudança de plataforma que o modelo de negócio agora exige. Você lançou um app web; agora precisa de um produto mobile-first porque a base de clientes se moveu. Construiu sobre um banco que não aguenta a próxima ordem de magnitude. Escolheu um stack no-code e o próximo tier de preço custa mais que reconstruir. Esses não são rewrites de preferência. São rewrites de aderência.

O terceiro é o portão de segurança ou compliance. SOC 2, HIPAA, PCI, LGPD, GDPR. Alguns regimes de compliance são alcançáveis a partir do código existente com esforço auditável. Outros não. Quando a arquitetura existente não consegue passar no audit sem mudanças mais profundas do que o desenho original suporta, o rewrite é real, e o custo é o custo de fazer o negócio que você agora faz.

O quarto é o engenheiro insubstituível que pediu para sair, deixando um codebase que ninguém mais consegue ler. Esse é o caso mais controverso, porque o movimento certo costuma ser contratar um novo engenheiro para aprender o código em vez de reescrever. Mas existe um limite. Quando o codebase é pequeno o bastante, a documentação é ruim o bastante, e quem sabia ler tudo já saiu, às vezes o custo de aprender é maior que o custo de reconstruir com um time que consegue manter a coisa nova. É raro. Se parece com a sua situação, busque uma segunda opinião com alguém que não vai faturar o rewrite.

Um teste de 4 semanas antes de financiar o rewrite

Se depois das cinco perguntas você ainda está considerando, não assine o rewrite. Rode um teste de quatro semanas antes.

Escolha a única feature ou módulo mais doloroso, aquele que aparece toda vez que o time reclama do codebase. Escolha a métrica de falsificação que vocês acordaram na pergunta 5. Dê quatro semanas para o time refatorar esse pedaço no lugar ou extrair em um serviço paralelo, e demonstrar melhora mensurável na métrica.

Quatro semanas custam mais ou menos R$ 80K a R$ 200K em tempo de engenharia para um time de estágio inicial, dependendo das taxas. Um rewrite completo é seis a doze meses e R$ 300K a R$ 1,2M no mesmo cenário, e isso é antes do custo de manutenção do segundo ano que você vai herdar no que quer que saia. O teste de quatro semanas é a forma mais barata possível de descobrir se o time consegue mudar esse sistema, ponto.

Se consegue: o rewrite é a resposta errada; siga refatorando. Se não consegue: agora você tem evidência, não opinião, e a conversa sobre rewrite pode acontecer com todo mundo olhando para os mesmos dados.

Perguntas frequentes

O que é um software rewrite? Um software rewrite é a decisão de descartar um codebase existente e construir uma substituição do zero. Em geral, substitui o código original na íntegra, não pedaço por pedaço, e mira chegar à paridade de features com o sistema antigo antes que clientes vejam qualquer coisa nova.

Quando reescrever é a resposta certa? Raramente. Os casos defensáveis são: um MVP que achou product-market fit e agora precisa ser engenheirado de verdade pela primeira vez; uma mudança de plataforma exigida pelo novo modelo de negócio; um regime de compliance que a arquitetura original não alcança; ou um codebase impossível de manter cujos engenheiros originais saíram. Em qualquer outro caso, um refactor direcionado ou um serviço paralelo é mais barato e mais rápido.

Quanto custa um software rewrite? Para um produto em estágio inicial, um rewrite real costuma rodar seis a doze meses de engenharia, o que dá em torno de R$ 300K a R$ 1,2M no Brasil e US$ 150K a US$ 600K nos EUA, dependendo do tamanho e da senioridade do time. Esse número não inclui o custo recorrente de manutenção de operar dois sistemas durante a migração nem o custo de oportunidade das features não entregues enquanto o rewrite acontece. O custo escondido de um rewrite é o que você para de construir enquanto ele rola.

Refazer ou refatorar? Refatore por padrão. Refactor é incremental, deixa você entregar valor visível ao cliente durante o trabalho, e tem uma taxa de sucesso muito mais alta. Escolha rewrite só quando o código existente não consegue chegar ao destino por nenhum caminho incremental. A “regra do 3” (refatore quando vir o mesmo padrão três vezes) é uma heurística interna útil, mas não se estende para codebases inteiros. Rewrites de sistema inteiro não são refactors em escala; são outro tipo de aposta, com outros modos de falha.

Por que a maioria dos software rewrites falha? Três motivos, em ordem de frequência. Não terminam antes do runway acabar, porque paridade de features é mais trabalho do que o time estimou. Entregam sem que a métrica de falsificação tenha sido batida, então ninguém consegue saber se o rewrite funcionou. E trocam um conjunto de problemas por outro, porque o time que escreveu o código original costuma ser o time que escreveu o rewrite, com as mesmas suposições.

Se você está lendo isso no meio de uma conversa sobre rewrite, a coisa mais útil que pode fazer amanhã não é aprovar o rewrite. É fazer a pergunta 1 e se recusar a seguir em frente sem um número.