Projeto de software travado: como resgatar um sistema abandonado pelo fornecedor sem começar do zero

O sistema está 80% pronto há oito meses. O fornecedor demora uma semana para responder mensagem, a última entrega foi em uma reunião que ninguém lembra mais, e a fatura continua chegando. Ou pior: a empresa que desenvolvia simplesmente fechou, o freelancer sumiu, e o que sobrou foi um repositório que ninguém na sua equipe sabe abrir. Quem já passou por um projeto travado sabe do que estou falando. E a pergunta que trava junto com o projeto é sempre a mesma: jogo tudo fora e recomeço, ou dá para aproveitar o que já foi pago?

Trabalho há anos herdando sistemas que outros times abandonaram. A boa notícia: na maioria dos casos, dá para resgatar. A notícia realista: nem sempre, e descobrir isso cedo é o que separa um prejuízo controlado de um prejuízo dobrado.

Por que projetos de software travam

Projeto travado quase nunca trava por um único motivo. É um acúmulo, e ele costuma seguir um padrão:

• Escopo que cresceu sem contrato acompanhar. Cada "só mais uma coisinha" empurrou o prazo. Em algum momento o fornecedor passou a perder dinheiro no projeto e priorizou outros clientes.
• Uma pessoa só sabia do sistema. O dev que construiu tudo saiu da empresa fornecedora, e ninguém mais consegue dar manutenção com segurança.
• Dívida técnica acumulada. As primeiras entregas saíram rápido porque cortaram caminho. Depois, cada nova funcionalidade quebrava duas antigas, e a velocidade caiu até parar.
• Pagamento desalinhado de entrega. Se o fornecedor já recebeu quase tudo e ainda deve metade do sistema, o incentivo para terminar desapareceu.

Entender qual desses foi o seu caso importa, porque a causa da trava define se o código que sobrou tem valor ou não. Escopo mal gerido costuma deixar código aproveitável. Dívida técnica profunda, nem sempre.

Primeiro passo: recuperar o que é seu

Antes de qualquer decisão técnica, resolva a posse. Vejo empresas descobrindo tarde demais que não têm acesso a nada. Confirme que você tem, em contas controladas pela sua empresa:

1. O código-fonte completo, em um repositório (GitHub, GitLab) onde sua empresa é dona, não convidada.
2. Acessos de infraestrutura: servidor, banco de dados, domínio, contas de cloud (AWS, Google Cloud, Vercel, Supabase).
3. Contas de serviços conectados: gateway de pagamento, envio de e-mail, APIs de terceiros.
4. Documentação e credenciais: senhas, chaves de API, variáveis de ambiente.
5. O contrato original, para verificar o que ele diz sobre propriedade intelectual do código.

Se o fornecedor ainda responde, negocie essa entrega antes de discutir qualquer pendência financeira. Código-fonte e acessos valem mais do que a última parcela em disputa. Se o fornecedor sumiu de vez e o código está em contas dele, o resgate fica mais caro e às vezes passa por caminho jurídico. Faça esse inventário na primeira semana, não no terceiro mês.

Resgatar ou reescrever: a conta que decide

Com o código em mãos, a decisão é técnica e financeira ao mesmo tempo. Não existe resposta única, mas existe conta certa. Um diagnóstico técnico feito por um time independente, algo entre 20 e 40 horas de trabalho, responde as perguntas que decidem:

Sinais de que dá para resgatar

• O sistema roda. Mesmo incompleto, as partes principais funcionam em produção ou em ambiente de teste.
• A tecnologia é atual e comum no mercado (React, Node.js, Python, Flutter). Encontrar quem dê continuidade é viável.
• O banco de dados está bem estruturado. Dados bem modelados são a parte mais cara de refazer.
• O que falta é funcionalidade, não fundação. Terminar telas e fluxos é diferente de reconstruir a base.

Sinais de que reescrever sai mais barato

• Nenhum dev experiente consegue rodar o projeto localmente em menos de alguns dias. Isso indica que cada mudança futura vai custar caro.
• A tecnologia é obscura, sem comunidade, ou uma plataforma proprietária que prende você ao fornecedor antigo.
• Não existe separação entre as partes do sistema: mexer em qualquer coisa quebra tudo.
• O custo estimado para terminar e estabilizar supera 70% do custo de refazer com base sólida. Nesse ponto, o código antigo virou passivo, não ativo.

O barato que sai caro aqui é o seguinte: insistir em "aproveitar" um código ruim por apego ao valor já pago. Esse dinheiro é custo afundado. A decisão certa olha para frente: qual caminho custa menos daqui em diante, incluindo manutenção nos próximos dois anos, não qual caminho honra o que já foi gasto.

Como escolher quem vai assumir o projeto

Assumir sistema alheio é uma habilidade específica. Muitos times bons em construir do zero são ruins em herdar código. Antes de assinar qualquer contrato, pergunta isso:

1. "Vocês já assumiram um sistema que não construíram? Me mostra um caso." Resposta vaga aqui é desclassificação.
2. "Qual o primeiro passo de vocês?" A resposta certa envolve um diagnóstico pago e limitado, com relatório do estado do código, antes de qualquer orçamento de continuidade. Quem orça a retomada inteira sem ler o código está chutando, e o chute vira aditivo de contrato depois.
3. "E se vocês concluírem que é melhor reescrever?" Um bom time aceita essa possibilidade e explica como aproveitaria o que existe: o banco de dados, as regras de negócio já mapeadas, os aprendizados do que não funcionou.
4. "Como fica a propriedade do código e dos acessos desta vez?" Tudo em nome da sua empresa, desde o primeiro dia, em contrato. Você não vai repetir o erro que criou esse problema.
5. "Qual o plano de entrega?" Retomada boa é incremental: estabilizar o que existe, entregar o bloco de maior valor, e só então evoluir. Desconfie de quem promete "terminar tudo" em uma entrega única.

O que esperar de prazo e custo na retomada

Faixas realistas, considerando um sistema web de porte pequeno a médio no Brasil em 2026:

• Diagnóstico técnico: R$ 5 mil a R$ 15 mil, 1 a 3 semanas. É o dinheiro mais bem gasto do processo, porque evita a decisão errada nas etapas seguintes.
• Estabilização do que existe: R$ 15 mil a R$ 50 mil, 3 a 8 semanas, dependendo do estado do código e da infraestrutura.
• Conclusão das funcionalidades pendentes: varia com o escopo restante, mas a referência é o custo por semana de um time sênior, entre R$ 10 mil e R$ 25 mil, com escopo fechado por bloco de entrega.

O que faz o número mudar: qualidade do código herdado, existência de documentação, complexidade das integrações e quanto do sistema já está em produção com usuários reais. Um sistema em produção exige mais cuidado (e mais custo) para mexer sem derrubar a operação.

Onde a OCA entra nessa história

Na OCA, resgatar produto travado é parte do dia a dia. Somos um time sênior que constrói e opera os próprios produtos, o Revo App, nossa plataforma de eventos, tem mais de 40 mil usuários em produção, então sabemos na prática o que um sistema precisa ter para continuar rodando dois anos depois do lançamento. É exatamente esse critério que aplicamos quando avaliamos o código de outra equipe: não julgamos estética, julgamos o que custa manter.

Nosso processo em retomadas segue o que descrevi acima: diagnóstico pago e limitado primeiro, relatório honesto depois, incluindo quando a resposta é "reescrever sai mais barato", e só então proposta de continuidade com escopo fechado por entrega e tudo registrado em nome do cliente. Sem promessa de milagre, com conta na mesa.

Converse com a OCA sobre o seu sistema

O próximo passo, mesmo sem contratar ninguém

Antes de falar com qualquer fornecedor, faça o inventário da primeira seção: código, acessos, contas, contrato. Anote o que sua empresa controla e o que está na mão do fornecedor antigo. Esse documento de uma página acelera qualquer diagnóstico, reduz o custo da retomada e, principalmente, mostra rápido o tamanho real do problema. Projeto travado não destrava sozinho, mas destrava mais barato quando você chega organizado na conversa.