Projeto de software abandonado pelo fornecedor: como resgatar o sistema sem decidir no escuro (o diagnóstico, os 4 caminhos e quanto custa retomar em 2026)

O sistema funciona, mais ou menos. O desenvolvedor que fez parou de responder no WhatsApp há três semanas. Ninguém na empresa sabe fazer deploy, a senha do servidor está no e-mail de alguém que já saiu, e o bug que trava a emissão de boletos toda segunda-feira continua lá. Enquanto isso, a equipe voltou a controlar parte da operação em planilha, “só até resolver”.

Nesse ponto, a primeira reação costuma ser uma de duas: procurar alguém para “dar uma olhada rápida” ou jogar tudo fora e começar de novo. Qualquer uma das duas pode estar certa. E as duas podem custar caro se forem decididas no escuro. Quem já passou por um projeto travado sabe do que estou falando: o prejuízo raramente vem só do código ruim. Ele vem da decisão tomada sem diagnóstico.

Este artigo trata do que fazer depois que o problema já aconteceu: como avaliar o que sobrou, quanto custa retomar em 2026 e quando reescrever vale mais que remendar.

Por que sistemas sob medida ficam abandonados no meio do caminho

Raramente é má-fé. Na maioria dos casos que chegam até nós, a causa é estrutural:

• Fornecedor de uma pessoa só. O projeto dependia de um único desenvolvedor. Ele arrumou um emprego CLT, adoeceu ou ficou sem tempo. Não houve passagem de bastão porque não havia para quem passar.
• Orçamento que não fechava. O preço foi baixo demais para o tamanho real do escopo. Na metade, o fornecedor percebeu que estava pagando para trabalhar e foi priorizando outros clientes até sumir.
• Escopo que cresceu sem contrato. Cada pedido novo entrou “de boa vontade”. Seis meses depois, ninguém sabe mais o que estava combinado, e o projeto vira uma discussão em vez de uma entrega.
• Nenhum processo de entrega. Sem repositório organizado, sem ambiente de testes, sem documentação. O sistema existe, mas só funciona na cabeça de quem escreveu.

Entender a causa importa porque ela indica o estado provável do código. Projeto abandonado por falta de tempo costuma ter código razoável e pouca documentação. Projeto abandonado por orçamento estourado costuma ter atalhos por todo lado.

Primeiro passo: recupere os acessos antes de qualquer conversa técnica

Antes de contratar um diagnóstico, garanta que a empresa controla o que é dela. Sem isso, nenhum time sério consegue nem orçar. A lista mínima:

1. Código-fonte completo, de preferência em um repositório (GitHub, GitLab, Bitbucket) numa conta da empresa, não do fornecedor.
2. Acesso ao servidor ou à nuvem onde o sistema roda (AWS, Google Cloud, Vercel, uma VPS), com conta de administrador.
3. Acesso ao banco de dados e a um backup recente. Este é o item mais crítico: código se reescreve, dado perdido não volta.
4. Domínio e DNS, registrados no CNPJ da empresa.
5. Contas de serviços terceiros: gateway de pagamento, envio de e-mail, SMS, lojas de aplicativo, APIs pagas.

Se o fornecedor ainda responde, peça tudo por escrito e com prazo. Se não responde, comece pelo que está no nome da empresa (domínio, nuvem, gateway) e recupere o resto pelo suporte de cada provedor. Na prática, isso leva de alguns dias a duas semanas. Se o código só existe no computador de quem sumiu, a conversa muda de figura e a reescrita entra na mesa logo de início.

Diagnóstico técnico do sistema: o que um time novo precisa olhar antes de dar preço

Desconfie de quem dá preço para retomar um sistema sem abrir o código. Ninguém consegue estimar trabalho em algo que não viu. Um diagnóstico bem feito responde a cinco perguntas:

1. O sistema sobe em outro ambiente?

É o teste mais simples e o mais revelador. Se um desenvolvedor novo não consegue rodar o projeto localmente em um ou dois dias, faltam configurações, variáveis de ambiente ou dependências que só existiam na máquina original.

2. As dependências ainda têm suporte?

Bibliotecas e frameworks com três ou quatro anos de atraso trazem falhas de segurança conhecidas e atualizações que quebram outras partes. Só atualizar um projeto parado há dois anos pode levar semanas.

3. Existe algum teste automatizado?

Sem testes, cada correção é uma aposta. O time vai gastar mais horas conferindo manualmente se a correção não quebrou outra coisa, e isso entra no preço.

4. O banco de dados faz sentido?

Código ruim com banco bem modelado tem conserto. Banco mal modelado contamina tudo o que é construído em cima dele, e corrigir depois exige migração de dados.

5. Quanto do escopo original já funciona?

Aqui a resposta é sua. Liste as funcionalidades combinadas e marque o que funciona, o que funciona com erro e o que nunca foi entregue. Essa lista pesa tanto quanto a análise do código.

Um diagnóstico desses custa, em 2026, entre R$ 6 mil e R$ 18 mil e leva de 1 a 3 semanas. O que move o número: tamanho do sistema, quantidade de integrações e se o banco está acessível. Parece um gasto a mais justo quando você já perdeu dinheiro. O barato que sai caro aqui é o seguinte: pular o diagnóstico e descobrir, no segundo mês de retomada, que o banco precisa ser refeito.

Retomar, reescrever parte ou começar do zero: quanto custa cada caminho em 2026

Com o diagnóstico em mãos, sobram quatro caminhos. As faixas abaixo valem para sistemas web de porte pequeno a médio, como uma gestão interna, um portal de clientes ou uma plataforma com painel administrativo.

Algumas observações que não cabem na tabela:

• Retomar nem sempre sai mais barato. Um sistema cheio de atalhos pode custar mais para estabilizar do que para refazer. O diagnóstico existe justamente para mostrar isso.
• A reescrita aproveita mais do que parece. Regras de negócio, telas que funcionam, dados e o aprendizado de uso não se perdem. Reescrever tendo o sistema antigo como referência é mais rápido do que começar só com uma ideia.
• O SaaS é uma saída legítima. Se o sistema travado era um CRM, um agendamento ou um controle financeiro comum, talvez ele nunca devesse ter sido sob medida. Migrar os dados para uma ferramenta pronta e aceitar as limitações dela pode ser a decisão mais lúcida.
• Qualquer caminho tem conta mensal depois. Hospedagem e manutenção de um sistema sob medida ficam, em geral, entre R$ 2 mil e R$ 8 mil por mês. Esse custo já existia antes, só não estava sendo pago. E isso fez parte do motivo do abandono.

Os 6 critérios que decidem entre remendar e reescrever o sistema

Não existe resposta única, mas existe conta certa. Antes de aprovar qualquer proposta, responda a estas perguntas junto com o time que fez o diagnóstico:

1. O sistema sobe e roda fora da máquina original? Se não sobe, some pelo menos duas semanas ao prazo de retomada.
2. O banco de dados está bem estruturado? Banco ruim empurra a decisão para a reescrita.
3. Quanto do escopo funciona hoje? Com mais de 60% funcionando, retomar costuma compensar. Com menos de 30%, a reescrita fica competitiva.
4. A stack tem suporte e gente disponível no mercado? Um framework abandonado deixa cada contratação futura mais cara.
5. Por quanto tempo a operação aguenta o improviso? Se a empresa perde dinheiro toda semana, estabilize o essencial primeiro, mesmo que a reescrita venha depois.
6. O sistema diferencia o seu negócio? Se não diferencia, considere seriamente o SaaS.

Uma regra prática: se a estimativa para retomar passa de 60% do custo de reescrever, prefira reescrever. Você paga um pouco mais e termina com um sistema que o time novo conhece por inteiro.

Antes de assinar qualquer contrato, pergunta isso: “Se vocês saírem amanhã, o que eu tenho em mãos?” A resposta precisa incluir código no repositório da empresa, acessos documentados e um passo a passo de deploy. Foi a falta disso que trouxe você até aqui.

Onde a OCA entra no resgate de um sistema

Assumir sistemas que outros times deixaram para trás faz parte do nosso trabalho no dia a dia. A gente começa pelo diagnóstico, entrega um relatório com o estado real do código e do banco e recomenda um caminho. Isso vale também quando o caminho é um SaaS pronto, e não um projeto com a gente.

Esse é o tipo de projeto que a gente constrói e mantém. O Gestão para Imobiliárias, por exemplo, é um sistema que cuida da operação de locação de ponta a ponta, com contratos, cobranças e repasses. Ele está em produção e evolui todo mês. É o tipo de software em que um bug na segunda-feira vira repasse atrasado na terça. Por isso, deploy, backup e documentação fazem parte da entrega, e não são um extra. Você pode ver esse e outros sistemas no portfólio de projetos da OCA.

O time é pequeno e sênior. Quem faz o diagnóstico é quem escreve o código depois, sem repassar o sistema para alguém que nunca o viu.

Próximo passo, de graça e ainda nesta semana: monte a lista dos cinco acessos deste artigo (código, servidor, banco, domínio e serviços terceiros) e marque o que a empresa já controla. Depois, escreva a lista de funcionalidades com três colunas: funciona, funciona com erro e nunca foi entregue. Com esses dois documentos, qualquer time sério consegue dizer em poucos dias se o seu sistema tem conserto.

Se quiser que a gente analise isso junto com você, é só mandar uma mensagem:

Converse com a OCA sobre o seu sistema