Software house atrasou seu projeto: o que fazer agora.

Você contratou uma software house, combinou prazo, e estourou. A entrega não saiu, ou saiu pela metade, ou saiu cheia de bug. Antes de qualquer ação, é preciso separar três coisas: o que o contrato diz, de quem é a culpa do atraso e qual o seu objetivo prático. A reação certa muda dependendo da resposta.

Este artigo cobre como diagnosticar a causa real do atraso, quais são seus direitos como contratante no Brasil e como blindar o próximo contrato para que isso não se repita.

Como saber de quem é a culpa

Atraso de software raramente tem culpado único. Antes de cobrar, mapeie os fatos:

• O escopo era claro desde o início? Se a proposta tinha "desenvolver sistema de gestão" sem detalhar funcionalidades, parte do atraso é da definição, não da execução.
• Você aprovou rapidamente cada etapa? Se aprovação de tela demorou semanas, o cronograma não tinha como caber.
• Surgiram pedidos novos durante o projeto? Toda mudança custa tempo. Se virou bola de neve, a culpa é compartilhada.
• O fornecedor avisou cedo dos riscos? Software house honesta avisa atraso assim que detecta. Quem só avisa na semana da entrega errou em comunicação.
• Houve troca de equipe no meio? Sinal clássico de problema interno do fornecedor.

Com essas respostas você sabe se o caso é negociar com firmeza, exigir compensação ou simplesmente realinhar.

Seus direitos como contratante

No Brasil, contrato de prestação de serviço de software se rege pelo Código Civil (arts. 593 a 609) e, em casos B2C, pelo CDC. Os direitos básicos quando há atraso:

• Receber o que foi contratado nas condições acordadas. Se o contrato fala em prazo, prazo é obrigação.
• Aplicar multa contratual se ela está prevista. A maioria dos contratos prevê multa moratória de 2% e juros de 1% ao mês.
• Exigir abatimento proporcional do preço se a entrega for parcial ou de qualidade inferior.
• Rescindir o contrato por inadimplemento substancial, recuperando valores pagos e proporcionais ao não entregue.
• Pedir indenização por danos comprovados: lucro cessante de campanha não lançada, custo de oportunidade documentado.

Importante: tudo isso depende do contrato. Se o seu contrato é de uma página dizendo só "desenvolver app por X reais", o caminho é mais difícil. Se tem cláusulas claras de SLA, multa e rescisão, é direto.

O que fazer agora, na ordem

Sequência prática, do menos para o mais agressivo:

• 1. Documentar tudo: e-mail, mensagem, ata de reunião. Sem registro, não há cobrança que se sustente.
• 2. Pedir reunião de status formal pedindo cronograma realista atualizado, não promessa vaga.
• 3. Notificar extrajudicialmente por e-mail registrado ou carta com AR, citando cláusulas do contrato e fixando prazo razoável (10 a 30 dias).
• 4. Renegociar com base de força: desconto, escopo reduzido em troca de entrega rápida, ou rescisão amigável.
• 5. Acionar advogado se nenhuma das anteriores resolveu. Mediação primeiro, ação só em último caso.

Sair quebrando o relacionamento sem documentar é fórmula de prejuízo para os dois lados — e geralmente o cliente é quem fica com o sistema pela metade.

Quando trocar de fornecedor é a melhor saída

Trocar de software house no meio do projeto é caro, mas às vezes é mais barato que continuar. Sinais de que vale considerar:

• Comunicação parou — mensagens sem resposta, reuniões canceladas, prazos sem justificativa.
• Código entregue não funciona em testes básicos e a equipe não tem plano para corrigir.
• Equipe técnica saiu e a substituição não conhece o projeto.
• Pedidos de aditivo crescem a cada semana, sem entrega correspondente.

Antes de trocar, garanta acesso ao código-fonte, à documentação, aos servidores e a todas as credenciais. Sem isso, a próxima fornecedora vai precisar refazer parte do trabalho.

Como blindar o próximo contrato

Para que isso não se repita, exija no próximo contrato:

• Escopo fechado por funcionalidade, com critério de aceite claro para cada uma.
• Cronograma com marcos intermediários e pagamento atrelado a entrega aceita, não a tempo decorrido.
• Multa por atraso com valor real, não simbólico. Se o fornecedor recusa, a confiança dele no próprio prazo é baixa.
• Cláusula de saída definindo o que acontece se o projeto for interrompido — quem fica com o código, como é a transição.
• Limite de aditivos — toda mudança requer aprovação por escrito com nova estimativa de prazo.
• Política clara de comunicação: relatório semanal, canal único, tempo máximo de resposta.

O modelo de trabalho que evita o problema

O motivo de tantas software houses atrasarem é simples: vendem mais do que conseguem entregar. Aceitam todo projeto que aparece, pulverizam o time, e quando o cronograma aperta, atrasam tudo.

Operar com cap mensal de projetos novos e contrato de escopo fechado em prazo curto resolve o problema na origem. Aqui na Skala Code são, no máximo, 2 projetos novos por mês — não por marketing, mas porque é o que a equipe entrega com o padrão prometido. MVP em 60 dias só é compromisso real se o calendário do time permite cumprir.