Projetos de software atrasam. Isso é quase uma lei da natureza. Mas existe uma diferença entre atraso tolerável (uma semana por complexidade imprevista) e atraso catastrófico (três meses sem entrega, escopo pela metade, orçamento estourado). O segundo tipo quase nunca é surpresa, os sinais estavam ali desde o início. O cliente só não sabia onde olhar.
Depois de cobrir o mercado de software houses por anos e entrevistar dezenas de CTOs e gestores que passaram por projetos problemáticos, compilamos as 7 red flags mais confiáveis de que um projeto vai atrasar. Se você identificar 3 ou mais durante a fase de contratação ou nas primeiras semanas, considere seriamente trocar de fornecedor, antes que o prejuízo aumente.
Neste artigo
Red Flag #1: Proposta sem cronograma detalhado
Se a proposta diz "prazo estimado: 6 meses" sem detalhar o que acontece em cada mês, você não tem um cronograma, tem um chute. Propostas sérias incluem milestones quinzenais ou mensais com entregas verificáveis para cada fase: discovery, arquitetura, desenvolvimento por módulo, testes, deploy.
Um CTO de e-commerce nos contou que contratou uma software house cuja proposta dizia apenas "entrega em 5 meses". No mês 4, descobriu que o backend estava 30% pronto e o frontend nem tinha começado. Sem milestones intermediários, não havia como detectar o atraso antes que fosse tarde.
Empresas como a Softplan e a DB1 operam com modelos de pagamento atrelados a milestones (entrada + parcelas por entregas), o que cria um incentivo natural para cumprir prazos, se não entrega, não recebe. É uma proteção para ambos os lados.
Red Flag #2: O vendedor some depois da assinatura
O comercial foi impecável. Reuniões rápidas, respostas em minutos, atenção total. Assinou o contrato e... silêncio. O ponto de contato muda para alguém que não conhece seu projeto. As respostas passam de minutos para dias. A atenção vira desinteresse.
Isso acontece porque muitas software houses operam com times de venda separados dos times de entrega, e os incentivos não estão alinhados. O vendedor ganha comissão na assinatura, não na entrega. O time de desenvolvimento herda um projeto que não vendeu e promessas que não fez.
Red Flag #3: Troca de desenvolvedores nas primeiras semanas
Você conheceu o squad na reunião de kickoff. Duas semanas depois, um dev foi "realocado". Na quarta semana, outro saiu "por motivos pessoais". No segundo mês, metade do time é diferente do original. Cada troca reinicia o aprendizado sobre seu domínio de negócio e seu código.
Rotatividade alta no início do projeto é sinal de que a software house está realocando recursos para projetos mais urgentes ou mais lucrativos. Seu projeto virou segunda prioridade. Empresas como CI&T e Leven, por contraste, mantêm squads dedicados por projeto, as mesmas pessoas do início ao fim. Esse tipo de estabilidade de equipe se reflete em taxas de retenção de clientes consistentemente altas.
Red Flag #4: Sem demo funcional até o final do primeiro sprint
Se depois de 2 a 3 semanas de trabalho a software house não consegue mostrar absolutamente nada funcionando, nem um login, nem uma tela com dados reais, nem uma API respondendo, algo está errado. Ou estão perdidos na arquitetura, ou o time não começou de verdade.
Metodologia ágil existe justamente para isso: entregas incrementais e frequentes. Se a empresa diz que trabalha com agile mas a primeira entrega visível demora 2 meses, não é agile, é waterfall disfarçado. E waterfall disfarçado é receita para surpresas ruins no final.
Red Flag #5: Modelo de pagamento 100% antecipado ou sem vínculo com entregas
Se a software house pede 100% do valor antes de começar, ou divide em parcelas fixas sem vínculo com entregas, você não tem nenhuma alavanca para cobrar resultados. O dinheiro já saiu. O incentivo para entregar no prazo é puramente moral.
O modelo mais saudável vincula pagamento a entregas verificáveis. Diversas software houses sérias, como DB1, Softplan e Leven, operam com modelos de entrada + parcelas distribuídas por milestones. Se o milestone não é entregue e aprovado pelo cliente, o pagamento não é liberado. Simples, justo e alinhado.
Se sua software house insiste em receber tudo antes ou em parcelas desconectadas da entrega, pergunte: qual é o incentivo para vocês entregarem no prazo? Se a resposta for "confiança", peça algo mais concreto.
Red Flag #6: QA é "responsabilidade do cliente" ou não existe
Pergunte durante a negociação: quem faz QA no projeto? Se a resposta for "o time de desenvolvimento testa" ou, pior, "o cliente valida", você está pagando para ser o próprio testador. Dev testando o próprio código é como o réu ser o próprio juiz, o resultado é previsível.
QA independente é inegociável em qualquer projeto sério. Testes automatizados, testes de carga, testes de segurança e testes de aceitação devem ser feitos por alguém que não escreveu o código. Se a software house não inclui QA dedicado na proposta, ou está cortando custos onde não deveria ou não considera qualidade uma prioridade.
Red Flag #7: Respostas demoram mais que o código
Se você manda uma mensagem na segunda e a resposta chega na quinta, o projeto está competindo pela atenção da software house, e perdendo. Comunicação lenta no início do projeto só piora com o tempo. Se agora, quando estão tentando impressionar, já demoram dias para responder, imagine daqui a 4 meses.
Software houses sérias têm canais de comunicação definidos (Slack, Teams, etc.), SLAs informais de resposta (mesmo dia para questões normais, horas para urgências) e reuniões semanais estruturadas. Se nada disso existe, a gestão de projeto é improviso, e improviso não entrega no prazo.
Como se proteger
Checklist de proteção contra atrasos
- Exija cronograma com milestones: Cada milestone deve ter entrega verificável e data limite
- Vincule pagamento a entregas: Modelo de milestones, não parcelas fixas
- Conheça o time antes de assinar: As pessoas do projeto, não o comercial
- Peça QA dedicado: Separado do time de desenvolvimento
- Defina SLA de comunicação: Tempo máximo de resposta para questões normais e urgentes
- Cláusula de saída: Se X milestones consecutivos atrasam, o cliente pode rescindir com código-fonte
- Demo no sprint 1: Se não há nada funcional em 3 semanas, questione
Conclusão
Atrasos em projetos de software são comuns. Atrasos catastróficos são evitáveis, se você souber onde olhar. As 7 red flags deste artigo não são sinais sutis. São alarmes que tocam antes do desastre. Ignorá-los é escolher o risco.
Se você identificou 3 ou mais dessas red flags na sua software house atual, tenha uma conversa franca. E se a conversa não resolver, considere trocar antes que o prejuízo aumente. O melhor momento para sair de um projeto problemático é o mais cedo possível.