Projeto de software travado: como resgatar um sistema abandonado pelo fornecedor sem jogar tudo fora (e quando reescrever compensa)

O sistema estava “90% pronto” em março. Hoje é setembro e ele continua 90% pronto. O desenvolvedor responde uma mensagem por semana, quando responde. Cada correção pedida quebra outra tela. Ninguém na empresa sabe onde o código está hospedado, e a fatura do servidor chega no cartão de alguém que você nunca viu. Enquanto isso, a operação continua na planilha que o sistema deveria substituir, e o dinheiro já investido pesa em cada reunião.

Quem já passou por um projeto travado sabe do que estou falando. A primeira reação costuma ser uma de duas: insistir com o mesmo fornecedor por mais seis meses ou jogar tudo fora e começar do zero com outra empresa. As duas podem estar certas. As duas também podem ser o erro mais caro do ano. Quem decide não é a raiva do momento, é um diagnóstico feito com método.

Por que projetos de software travam (e quase nunca é culpa de uma pessoa só)

Já herdei sistemas abandonados suficientes para dizer que o padrão se repete. O problema raramente é um desenvolvedor incompetente. Na maioria das vezes é uma estrutura de projeto que deixava o trabalho travar sem que ninguém percebesse a tempo.

• Escopo aberto e pagamento por prazo, não por entrega. Sem marcos verificáveis, “90% pronto” é uma sensação, não uma medida.
• Um único dev segurando tudo. Quando ele fica sem tempo, pega outro cliente ou adoece, o projeto para junto.
• Nenhum ambiente de homologação. O cliente só vê o sistema quando ele está “quase pronto” e só aí descobre que ele não faz o que precisava.
• Contas no nome do fornecedor. Repositório, servidor, banco de dados e domínio ficam fora do seu controle.
• Dívida técnica acumulada em silêncio. Atalhos tomados para cumprir prazo que, somados, fazem cada funcionalidade nova custar o triplo.

Entender a causa importa porque, se a estrutura não mudar, ela vai se repetir com o próximo fornecedor.

As primeiras 72 horas: o que fazer antes de qualquer decisão técnica

Antes de discutir se o código presta, garanta que ele é seu e que você consegue acessá-lo. Essa etapa não exige conhecimento técnico. Exige insistência.

1. Recupere os acessos. Repositório de código (GitHub, GitLab, Bitbucket), conta de nuvem (AWS, Google Cloud, Vercel, Supabase), banco de dados, domínio, contas nas lojas da Apple e do Google (se houver app), serviço de e-mail e gateway de pagamento. Peça tudo por escrito, com a titularidade transferida para um e-mail da empresa.
2. Faça backup do banco de dados e do código. Hoje, não na semana que vem. Se o fornecedor desligar o servidor por falta de pagamento, os dados vão junto.
3. Congele as mudanças. Pare de pedir correções pontuais ao fornecedor atual enquanto não houver diagnóstico. Cada remendo feito sem critério aumenta o custo do resgate.
4. Levante o que já foi pago e o que foi entregue. Contrato, propostas, notas fiscais e o histórico de mensagens com os combinados. Isso vira insumo para o diagnóstico e, se for o caso, para uma conversa jurídica.
5. Liste o que a operação precisa hoje. Não o escopo original de dois anos atrás, e sim as três ou quatro coisas que realmente fazem falta no dia a dia.

Se o fornecedor se recusar a entregar o acesso ao código que você pagou, o problema deixou de ser técnico. Aí vale procurar um advogado, com o contrato em mãos.

Diagnóstico técnico do sistema: quanto custa e o que ele precisa responder

O diagnóstico é uma auditoria do sistema feita por um time sênior que não tenha interesse em vender a reescrita. Em 2026, para um sistema web de porte pequeno ou médio, espere algo entre R$ 5 mil e R$ 15 mil, com prazo de 1 a 3 semanas. O que move esse número: o tamanho do código, a quantidade de integrações, se existe documentação e se há um app mobile junto.

Antes de assinar qualquer contrato, pergunta isso: o que exatamente eu vou receber no final? Um bom diagnóstico entrega respostas objetivas para estas perguntas:

• O sistema roda numa máquina nova a partir do repositório, sem depender do desenvolvedor original?
• O deploy é reproduzível ou alguém faz tudo na mão, de um jeito que só ele sabe?
• As bibliotecas e o framework estão em versões com suporte ou há dependências abandonadas?
• Existem falhas de segurança evidentes, como senhas no código, dados pessoais expostos ou falta de controle de acesso?
• O modelo de dados sustenta a operação real ou vai exigir uma migração pesada?
• Quanto do que foi prometido funciona de fato, testado de ponta a ponta?
• Qual a estimativa, em horas e em reais, de cada caminho possível?

Desconfie de quem olha o sistema por uma tarde e já recomenda reescrever tudo. E desconfie na mesma medida de quem promete “terminar em um mês” sem abrir o código.

Estabilizar, refatorar, reescrever ou trocar por SaaS: os quatro caminhos

Não existe resposta única, mas existe conta certa. Com o diagnóstico em mãos, a decisão fica entre quatro opções. Os valores abaixo são faixas para sistemas web de porte médio em 2026. Servem como ordem de grandeza, não como orçamento.

O barato que sai caro aqui é o seguinte

Reescrever parece a opção limpa, e por isso seduz. Só que uma reescrita costuma custar entre 60% e 100% do que custaria um sistema novo, porque as regras de negócio escondidas no código antigo precisam ser redescobertas uma a uma. Durante meses você paga por dois sistemas: o velho, que ainda roda, e o novo, que ainda não chegou. Reescrever só compensa quando o diagnóstico mostra que consertar custa quase o mesmo que refazer, ou mais.

A saída que ninguém sugere

Às vezes o sistema travou porque nunca deveria ter sido sob medida. Se o que a empresa precisa hoje é um CRM comum, um ERP padrão de mercado ou um agendador, migrar os dados para um SaaS e encerrar o projeto pode ser a decisão mais barata. Dói admitir depois de ter gastado, mas o dinheiro já investido não volta investindo mais. Custo afundado não é argumento.

Checklist para decidir sem depender de quem vai executar

Leve estas perguntas para a reunião, junto com o diagnóstico. Se a maioria das respostas for “sim”, salvar o sistema tende a valer mais do que reescrever.

1. Você tem acesso total ao código, ao banco e às contas de infraestrutura, tudo no nome da empresa?
2. O sistema já roda em produção em pelo menos parte da operação, com dados reais?
3. A stack está em versões com suporte e tem desenvolvedores disponíveis no mercado brasileiro?
4. O custo estimado para estabilizar é menor que metade do custo de reescrever?
5. As regras de negócio que estão no código ainda valem para a operação de hoje?
6. Existe um núcleo que funciona bem e pode servir de base para o resto?

E uma regra vale para qualquer caminho: o novo contrato precisa ter marcos de entrega verificáveis, ambiente de homologação desde a primeira semana e todas as contas no nome da empresa. Sem isso, você só está trocando de fornecedor para travar de novo daqui a um ano.

Onde a OCA entra num resgate de sistema

Resgatar sistema que outro time largou pela metade é o tipo de projeto que a gente pega com frequência. O trabalho começa sempre pelo diagnóstico, com escopo e preço fechados, e termina com uma recomendação por escrito. Às vezes a recomendação é “não reescreva”. Às vezes é “migre para um SaaS e economize”. Se a gente não acredita que salvar vale a pena, a gente fala.

A régua que usamos para julgar se um sistema aguenta produção é a nossa própria operação: o Revo App, plataforma de eventos que a OCA mantém com mais de 40 mil usuários cadastrados, mais de 300 eventos por mês e um checkout que converte 90%. Manter isso rodando todo dia é o que ensina a diferença entre o código que impressiona na demo e o código que aguenta dois anos de uso. Você pode ver esse e outros sistemas em produção no portfólio de projetos da OCA.

O próximo passo, mesmo que você não contrate ninguém agora

Antes de conversar com qualquer fornecedor novo, faça duas coisas nesta semana: recupere todos os acessos listados acima e escreva, em uma página, as quatro coisas que a operação precisa que o sistema faça hoje. Só isso já coloca você numa posição muito melhor para negociar, com a OCA ou com qualquer outro time.

Se quiser uma segunda opinião sobre o seu caso, com um diagnóstico honesto do que vale salvar e do que não vale:

Converse com a OCA sobre o seu sistema