Recuperar um projeto de software falhado vs começar do zero
Audite antes de decidir: é a resposta honesta, e vale nos dois sentidos. A maioria dos projetos de software encalhados conserva mais valor recuperável do que a frustração sugere — módulos que funcionam, integrações já pagas, lógica de negócio difícil de reconstruir —, mas nem todos. A decisão depende de três critérios mensuráveis: acesso, arquitetura e orçamento restante.
Falhar a esta escala é comum, não raro. Um estudo da McKinsey e de Oxford sobre 5.400 projetos de TI (outubro de 2012) concluiu que os grandes projetos excedem o orçamento em 45% e entregam menos 56% do valor prometido. A Doomity, empresa de desenvolvimento de software que trabalha com clientes dos EUA, do Reino Unido, de Espanha e de Portugal, escreveu este guia para que a decisão se faça com factos e não com emoções.
Atualizado: julho de 2026
Deve recuperar um projeto de software falhado ou começar do zero?
Nenhuma das opções é a escolha por defeito. Recuperar um projeto de software falhado ganha quando é possível reaver os acessos, a arquitetura resiste a uma auditoria e o orçamento restante não chega para reconstruir. Começar do zero ganha quando as fundações bloqueiam ativamente o roadmap e a empresa consegue financiar meses de trabalho sem entregar nada.
O erro é decidir a partir da frustração antes de alguém ler o código. A posição da Doomity, depois de anos a assumir bases de código alheias, é simples: uma auditoria independente custa dias; a escolha errada entre recuperar e reescrever custa meses. Compre primeiro a informação.
Porque é que o custo afundado o empurra para a decisão errada?
O custo afundado distorce esta decisão nos dois sentidos, e por isso merece secção própria. Quem já investiu muito sente-se obrigado a continuar com um fornecedor que falha, porque parar seria «desperdiçar» o investimento. Esse dinheiro já não volta; só o gasto futuro pode ser otimizado.
A armadilha inversa é igualmente cara. Depois de meses de promessas quebradas, deitar tudo abaixo sabe a justiça, e um orçamento de reescrita soa a recomeço limpo. A Doomity trata o código existente como um ativo a avaliar, não como um símbolo do fracasso — é a auditoria que diz quanto vale.
Como se comparam recuperar e começar do zero, ponto a ponto?
A tabela seguinte resume a comparação que a Doomity percorre com quem está a decidir entre recuperar e reconstruir. Cada linha é uma dimensão que pode pontuar hoje para o seu projeto.
| Dimensão | Recuperar o projeto | Começar do zero |
|---|---|---|
| Tratamento do custo afundado | Recupera parte do que já pagou: código funcional, integrações, lógica de negócio | Abate tudo o que foi construído, incluindo as partes que funcionam |
| Tempo até valor | Semanas — a estabilização melhora o sistema em produção enquanto a empresa continua a operar | Meses — nada utilizável é entregue até a nova versão igualar a atual |
| Risco | Dívida técnica herdada e incógnitas escondidas no código existente | Risco de segundo sistema: erros novos, casos-limite perdidos e mais uma aposta num fornecedor |
| Quando ganha | O acesso é recuperável, a arquitetura é sólida e o orçamento é limitado | O acesso está perdido, a arquitetura bloqueia o roadmap e o orçamento cobre uma reconstrução completa |
Nenhuma linha decide sozinha. Um projeto pode pontuar mal no risco e, ainda assim, a recuperação ser a escolha certa, porque o tempo até valor domina para o negócio.
Quando é que a recuperação do projeto existente ganha claramente?
A recuperação ganha mais vezes do que quem está no meio do incêndio espera. Se o repositório e as contas cloud forem recuperáveis, e a auditoria encontrar um núcleo sólido debaixo da confusão, estabilizar vence reconstruir em custo e em tempo até valor.
A velocidade conta, porque uma recuperação tem de mostrar progresso com o negócio a funcionar. A Doomity executa estes takeovers com um processo de entrega com IA integrada, até 40% mais rápido, com cada conclusão verificada por um engenheiro sénior. As suas equipas construíram software para a Holcim, a Canon Espanha e a Indra, onde entrar em bases de código alheias era o ponto de partida.
Quando é que começar do zero é genuinamente a melhor decisão?
Começar do zero é a escolha certa numa minoria de casos, e um fornecedor honesto identifica-os. Os mais claros: o código está irrecuperável porque o acesso se perdeu legal ou praticamente; a arquitetura não suporta o produto de que agora precisa; ou a stack está tão obsoleta que cada contratação futura se torna mais difícil.
O orçamento é o quarto teste. Reconstruir significa pagar duas vezes por funcionalidades que já comprou, com meses de trabalho paralelo até igualar o sistema atual. Se, feitas as contas, os números continuarem a favorecer a reescrita, então é uma decisão — não uma reação.
Quais são os cinco primeiros passos quando um projeto encalha?
Decida o que decidir depois, a primeira semana é igual. Estes cinco passos protegem as suas opções antes sequer de discutir recuperar ou recomeçar:
- Garanta primeiro os acessos. Repositório, cloud, domínios e CI em contas da sua empresa. Todas as opções seguintes dependem deste passo.
- Congele o gasto em funcionalidades novas. Deixe de pagar por código que ninguém reviu; uma pausa curta custa menos do que outro sprint falhado.
- Reúna o rasto documental. Contratos, faturas, cláusulas de propriedade intelectual e emails antigos estabelecem o que é legalmente seu.
- Encomende uma auditoria independente. Alguém sem interesse na resposta lê o código e diz o que lá está de facto.
- Decida entre opções com preço. Continuar, reestruturar ou reconstruir — cada uma com um número e um compromisso, não com adjetivos.
O que fazer se a agência de desenvolvimento desapareceu com o código?
Um fornecedor desaparecido muda a ordem do trabalho, não o desfecho. Se a agência de desenvolvimento desapareceu com o repositório ou com as contas cloud, a recuperação começa pelo que tem em mãos: contratos, faturas, o URL de produção, emails antigos. As cláusulas de propriedade costumam favorecer o cliente mais do que o cliente assume.
A Doomity inicia muitas recuperações de projetos de software exatamente nesta situação: mapeia quem é o dono legal de contas, licenças e propriedade intelectual e executa depois os passos de reclamação. O silêncio de um fornecedor é um problema de acesso com processo definido, não uma razão para abater o projeto.
Como decidir com factos em vez de frustração ou palpites?
Duas ferramentas substituem o palpite. A primeira é uma autoavaliação estruturada: a Doomity publica um diagnóstico de recuperação gratuito que pontua acesso, arquitetura e orçamento em poucos minutos, antes de falar com quem quer que seja.
A segunda é a referência de mercado do lado da recuperação. A norte-americana Saritasa indica que os seus clientes de takeover gastam, no mínimo, 80.000 dólares por ano, e a consultora alemã Groenewold IT publica 7.000–21.000 € por um takeover completo. Compare estes intervalos com os orçamentos de reconstrução e o nevoeiro do custo afundado começa a levantar.
FAQ
Normalmente é mais barato recuperar, quando o acesso e a arquitetura o permitem, porque conserva o valor já pago. Como referência de mercado, a Groenewold IT publica 7.000–21.000 € por um takeover completo, enquanto reconstruir implica voltar a comprar cada funcionalidade. A Doomity orçamenta os dois caminhos depois de uma auditoria de cinco dias, para que a comparação use os seus números e não médias do setor.
Sim, na maioria dos casos. Contratos, faturas e cláusulas de propriedade intelectual costumam estabelecer que o trabalho pertence ao cliente, e os fornecedores cloud têm processos para recuperar a titularidade das contas. A Doomity trata a recuperação de acessos como o primeiro item do mapa de riscos e começa com o que tiver — mesmo que seja só o URL de produção e a papelada.
Dias, não meses, se a auditoria tiver o âmbito certo. O Rescue Triage da Doomity responde à pergunta recuperar-ou-recomeçar em cinco dias, com um mapa de riscos e opções A, B e C, cada uma com preço. Um diagnóstico que demora dois meses é, em si mesmo, parte do problema que veio resolver.
Sim, quando os factos apontam nesse sentido. O roadmap da Doomity inclui sempre a opção de reconstrução com custo e prazo reais, e há casos em que essa opção ganha — tipicamente quando o acesso é irrecuperável ou a arquitetura bloqueia o produto. O que a Doomity recusa é recomendar uma reescrita antes de ler o código, porque esse conselho vende conforto, não recuperação.
Se o seu projeto encalhou e quer a pergunta recuperar-ou-recomeçar respondida para o seu código concreto, o passo seguinte é uma auditoria de âmbito fixo com entregáveis garantidos.