Tempo de leitura: 11 min · Atualizado em 03/09/2026
Se a empresa contratada parou de responder e não entrega mais nada, isso é descumprimento do contrato. Você pode notificar formalmente, encerrar o contrato por culpa da fornecedora, cobrar de volta o que pagou pelas etapas não concluídas e exigir a entrega do código já produzido — mas o resultado depende do que ficou escrito no contrato e das provas que você reunir.
Como saber se é abandono, e não só atraso
Todo projeto de tecnologia atrasa em algum grau, e isso sozinho não é abandono. O que caracteriza abandono é a ausência de resposta continuada: o time some, os prazos combinados passam sem entrega, o suporte para de funcionar, e tentativas de contato por e-mail, telefone ou mensagem ficam sem retorno por semanas. Se ainda existe algum diálogo, o caminho é cobrar o cumprimento do prazo. Quando o contato simplesmente cessa, o caso muda de categoria: deixou de ser atraso e virou abandono do contrato. Vale registrar desde já datas de última entrega funcional, última resposta e tentativas de contato — essa linha do tempo sustenta qualquer notificação ou cobrança depois.
Abandono é descumprimento do contrato
Quando a empresa contratada para desenvolver um sistema simplesmente para de entregar, ela está descumprindo o que assinou — é deixar de prestar o serviço pelo qual foi paga. Esse descumprimento abre três frentes para quem contratou: encerrar o contrato por culpa da fornecedora, pedir de volta os valores pagos por etapas não entregues, e discutir o destino do que já foi produzido. Nenhuma dessas frentes é automática: dependem do que o contrato previu, de quanto foi de fato entregue funcionando, e da qualidade das provas reunidas. Um contrato com etapas claras e critério de aceite torna essa discussão bem mais objetiva do que um orçamento genérico trocado por e-mail.
Notifique formalmente antes de qualquer outra coisa
Antes de cobrar, processar ou tentar recuperar o código sozinho, o recomendado é notificar a empresa por escrito, com prazo razoável para retomada ou explicação. Isso dá à outra parte uma última chance de se manifestar e cria prova formal de que houve tentativa de solução. Uma notificação bem feita costuma trazer:
- Resumo do que foi contratado e do que já foi pago, com datas e valores;
- Lista das etapas previstas e quais não foram entregues;
- Registro da ausência de resposta, com as datas dos contatos feitos;
- Prazo objetivo (geralmente entre 5 e 15 dias) para a empresa se posicionar;
- Aviso de que, sem resposta, o contrato será considerado rescindido por culpa dela.
Enviar por um canal que comprove entrega — e-mail com confirmação, carta com aviso de recebimento, ou mensagem em canal que a outra parte reconhecidamente usa — importa mais do que o texto em si.
O que pode ser cobrado de volta
A regra prática: o que foi pago por uma etapa não entregue, ou entregue sem funcionar, pode ser cobrado de volta. Se o contrato previu pagamento por marcos (por exemplo, 30% na assinatura, 30% no módulo intermediário, 40% na entrega final) e o projeto parou após o primeiro marco, a discussão recai sobre os valores pagos além do que foi de fato entregue. Quando o pagamento foi antecipado e único, sem vínculo com etapas, a conta fica mais aberta e costuma exigir um laudo técnico avaliando quanto do sistema foi construído. Este blog já tratou de situações parecidas, como o sistema entregue cheio de falhas e a agência de marketing que não entrega os resultados prometidos em contrato — a lógica de cobrar de volta é semelhante, mas aqui nada foi concluído: o projeto simplesmente parou no meio.
De quem é o código já produzido
Essa é a pergunta que mais gera dúvida, e a resposta depende primeiro do que o contrato disse sobre propriedade do que estava sendo desenvolvido. Contratos bem estruturados costumam prever que o código, à medida que é produzido e pago, passa a pertencer ao contratante — a fornecedora presta um serviço, recebe por ele, e o resultado é do cliente. Nesse cenário, exigir o repositório e os arquivos-fonte é consequência direta do que já foi pago, sem depender de encerramento formal do contrato.
Quando o contrato não previu nada sobre isso — o que é comum em contratos enxutos, fechados com freelancers ou pequenas consultorias, que só mencionam “entrega do sistema” ao final — a tese mais forte para o contratante é que o que já foi pago corresponde a um serviço prestado, e o produto desse serviço, ainda que incompleto, deveria acompanhar o pagamento. Não é garantia automática: depende de como o caso é apresentado e das provas reunidas, mas é a base para negociar a entrega e, se necessário, cobrá-la formalmente depois.
Seu caso envolve uma situação semelhante?
Cada caso possui particularidades e deve ser analisado individualmente. Para informações sobre análise jurídica do seu caso, entre em contato com o escritório.
As provas que decidem esse tipo de caso
Esse tipo de discussão costuma se resolver com três provas: o contrato (ou, na falta dele, propostas e mensagens que mostrem o combinado), os comprovantes de pagamento por etapa, e o histórico de comunicação mostrando a ausência de resposta. Prints de conversas, tickets não respondidos e o histórico de acesso ao repositório, quando existe, ajudam a mostrar em que ponto o trabalho parou. Quando possível, uma avaliação técnica independente sobre o estado do que foi entregue transforma uma alegação em algo mensurável, e pesa tanto numa negociação quanto numa eventual ação judicial.
Em que isso difere de sistema com falhas ou de recusa em entregar o código
Vale separar essa situação de duas outras parecidas, já tratadas neste blog. Quando o sistema foi entregue mas cheio de erros, o contrato chegou ao fim e a discussão é sobre a qualidade do que foi entregue. Quando o fornecedor conclui o contrato e depois se recusa a entregar o código-fonte, o projeto terminou, mas a empresa retém o resultado. Já o abandono no meio é uma terceira situação: o projeto nunca chegou a lugar nenhum, não existe “produto final” para avaliar, e muitas vezes nem existe formalmente um fim de contrato — a empresa só parou de responder.
| Situação | Ponto central da discussão |
|---|---|
| Sistema entregue com falhas | Qualidade e funcionamento do que foi entregue |
| Fornecedor recusa entregar o código após o fim do contrato | Retenção do resultado já concluído |
| Projeto abandonado no meio | Ausência de entrega, cobrança de valores e destino do código incompleto |
Essa distinção muda a estratégia: no abandono, o primeiro movimento é formalizar que o contrato acabou por culpa da contratada, e só então tratar da devolução de valores e da entrega do que existe. Situação diferente é a do sistema que ficou dias fora do ar por falha do fornecedor de tecnologia, em que o produto existe e está em operação — ali o problema é a interrupção do serviço, não a ausência de entrega.
Negociar primeiro ou já entrar na Justiça?
Na maioria dos casos, faz sentido tentar a notificação e a negociação direta antes de judicializar: empresas que abandonam um projeto costumam ter razões práticas para isso — caixa apertado, perda da equipe técnica, encerramento das atividades — e uma cobrança formal com prazo claro muitas vezes já destrava a entrega ou viabiliza um acordo de devolução parcial. Quando a negociação não avança, ou a empresa desaparece de vez, a via judicial formaliza o fim do contrato, cobra os valores pagos e pode obrigar a entrega do código e dos acessos. Isso costuma aparecer junto com casos de fornecedores que mantêm senhas mesmo depois do vínculo acabado, como o do prestador de TI que mantém as senhas dos sistemas após o fim do contrato, situação que pode ser tratada na mesma ação.
Como reduzir esse risco no próximo contrato
Para quem ainda vai contratar um desenvolvimento, alguns pontos reduzem bastante esse risco: pagamento vinculado a etapas com critério de aceite, cláusula expressa de que o código pertence ao contratante à medida que é pago, acesso ao repositório desde o início do projeto, e uma cláusula de rescisão com prazo de resposta e entrega obrigatória do que foi produzido em caso de encerramento antecipado. Nada disso evita que uma empresa abandone um projeto, mas tudo isso facilita muito recuperar o que foi pago e o que foi produzido quando acontece.
Perguntas frequentes
Quanto tempo sem resposta já caracteriza abandono?
Não há número fixo. Na prática, várias semanas sem entrega e sem resposta a diferentes tentativas de contato, sem qualquer justificativa, costuma bastar. O que mais pesa é o padrão: silêncio repetido depois de cobranças formais.
Posso parar de pagar as parcelas que faltam?
Se a empresa parou de entregar, normalmente não há mais obrigação de pagar pelas etapas futuras. Mas isso deve vir acompanhado da notificação formal encerrando o contrato por culpa dela, para deixar claro que a suspensão tem motivo.
Tenho direito ao código mesmo sem isso escrito no contrato?
É possível defender esse direito com base no que já foi pago pelo serviço, mesmo sem cláusula específica. A força do argumento varia conforme as provas de pagamento e do que foi combinado — por isso reunir contrato, propostas e comprovantes ajuda bastante.
E se a empresa simplesmente sumir ou fechar as portas?
Ainda é possível notificar formalmente, inclusive por via judicial quando não há resposta, cobrar os valores pagos e buscar acesso ao que foi produzido, especialmente se os arquivos estavam em serviços de nuvem ou repositórios aos quais o contratante tenha algum direito de acesso.
Vale a pena pedir um laudo técnico sobre o que já foi desenvolvido?
Em projetos de maior valor ou complexidade, sim. O laudo ajuda a quantificar o que foi entregue frente ao total contratado e a mostrar se o código tem aproveitamento real, o que fortalece tanto a negociação quanto uma cobrança formal.
Preciso de advogado só para notificar a empresa?
A notificação pode ser redigida com orientação jurídica e nem sempre exige entrar na Justiça de imediato — muitas vezes ela sozinha já resolve. Quando não resolve, o acompanhamento jurídico ajuda a reunir as provas certas para o próximo passo.
Conclusão: agir rápido e documentar tudo
Quando uma empresa de tecnologia some no meio de um desenvolvimento, o maior risco é prático: quanto mais tempo passa sem notificação formal e sem reunir provas de pagamento e comunicação, mais difícil fica reconstruir o caso depois. Notificar, documentar e buscar acesso ao que já foi produzido é o que dá mais força para recuperar valores pagos e o código já desenvolvido.
Cada contrato é diferente, e o que foi ou não previsto sobre propriedade do código e etapas de pagamento muda bastante o que pode ser cobrado. Avaliar o contrato específico e a documentação disponível é o caminho mais seguro antes de negociar diretamente ou formalizar uma cobrança maior.
Fontes oficiais consultadas
- Planalto — Código Civil (Lei 10.406/2002), disposições sobre contratos e inadimplemento
- INPI — Instituto Nacional da Propriedade Industrial, orientações sobre programas de computador e titularidade de software
- Planalto — Lei 9.609/1998, Lei de Software, sobre proteção da propriedade intelectual de programas de computador
Artigos relacionados
- Empresa de tecnologia entregou aplicativo mobile com falhas graves de segurança em dados de usuários LGPD: quem responde?
- Contrato de desenvolvimento de software não prevê propriedade intelectual do código fonte: de quem é a titularidade?
- Empresa terceirizada de TI vazou dados de clientes: quem responde?
- O sistema usado pela empresa ficou dias fora do ar por falha do fornecedor de tecnologia: dá para cobrar o prejuízo?
Veja também nosso conteúdo completo sobre direito digital.
Seu caso envolve uma situação semelhante?
Cada caso possui particularidades e deve ser analisado individualmente. Para informações sobre análise jurídica do seu caso, entre em contato com o escritório.
