Contratar uma software house é uma das decisões mais arriscadas que um gestor de médio e grande porte toma. O mercado está cheio de empresas que prometem o mesmo: metodologia ágil, equipe sênior, entrega no prazo. E a maioria dos gestores não tem base técnica para distinguir quem entrega de quem apenas apresenta bem.
Este roteiro foi construído com base em padrões recorrentes de projetos que fracassaram — e no que, em retrospecto, revelava os problemas antes de começar.
Por que a maioria das contratações dá errado
Projetos de software falham por três razões principais, em ordem de frequência:
- Escopo mal definido: o que o cliente entendeu não é o que a software house orçou
- Entrega sem qualidade técnica: o sistema "funciona" em demo mas quebra em produção
- Comunicação que desaparece: relatórios de progresso que não refletem a realidade
Nenhum desses problemas aparece na proposta comercial. Aparecem nas respostas às perguntas certas — quando você as faz antes de assinar.
As 12 perguntas que revelam a maturidade da empresa
Sobre o processo de discovery e escopo
1. "Como vocês evitam que o escopo mude no meio do projeto?"
Respostas ruins: "temos um processo ágil muito maduro" (vago) ou "o cliente decide" (sem estrutura). Respostas boas: descrição de como fazem discovery antes do desenvolvimento, como documentam requisitos, como tratam mudanças de escopo formalmente (com impacto em custo e prazo).
2. "Posso ver o contrato antes de fechar? Qual é a cláusula de cancelamento?"
Empresas sérias têm contratos claros com propriedade intelectual explicitamente transferida ao cliente, cláusulas de confidencialidade, e saída do projeto sem penalidades abusivas. Desconfie de contratos vagos ou resistência em mostrar antes de assinar.
3. "O que acontece se surgir uma funcionalidade que não estava no escopo?"
Deve haver um processo claro: registro formal da mudança, estimativa de impacto em prazo e custo, aprovação do cliente antes de executar. Empresas que simplesmente "absorvem" mudanças no começo cobram caro no final — ou entregam menos.
Sobre a equipe técnica
4. "Quem vai trabalhar no meu projeto? Posso conhecer essas pessoas?"
O "equipe sênior" da proposta comercial frequentemente não é a equipe que vai trabalhar no seu projeto. Peça para conhecer especificamente quem vai ser o tech lead e os devs principais. Se a empresa hesitar, é sinal de que a equipe real é diferente da apresentada.
5. "Qual é a rotatividade de equipe vocês têm? O que acontece se o principal desenvolvedor sair?"
Alta rotatividade é um dos maiores riscos em projetos de software. Uma empresa madura tem plano de contingência e documentação que não depende de pessoas específicas.
6. "Vocês trabalham com testes automatizados? Qual é a cobertura mínima exigida?"
Sem testes automatizados, cada nova funcionalidade aumenta o risco de quebrar o que já funcionava. Empresas que não mencionam testes espontaneamente normalmente não os fazem. Peça para ver um exemplo de código com testes de um projeto anterior.
Sobre cases e prova social
7. "Podem me mostrar um sistema em produção que vocês entregaram? Posso falar com o cliente?"
Esta é a pergunta mais reveladora. Empresas sérias têm clientes que topam uma conversa de 15 minutos. Se a resposta for "temos NDA com todos os clientes" ou "não é possível no momento", desconfie. Todo portfólio tem pelo menos um cliente que permite referência.
8. "Qual foi o projeto mais difícil que vocês tiveram? O que deu errado e como resolveram?"
Perguntas sobre fracassos revelam maturidade. Empresas que só falam de sucessos não aprendem com erros — ou mentem. Uma resposta honesta sobre um projeto difícil, com o que foi feito para resolver, é um sinal positivo.
Sobre gestão e transparência
9. "Como vou acompanhar o andamento do projeto semana a semana?"
Deve haver rituais claros: reuniões de sprint, acesso a um board (Jira, Linear, Trello), relatório semanal ou quinzenal com o que foi feito e o que está bloqueado. "Reunião quando necessário" não é processo — é risco.
10. "O código vai ser meu desde o início ou só na entrega final?"
O repositório deve ser do cliente desde o primeiro commit. Empresas que "entregam o código no final" criam dependência. Se o projeto parar no meio, você precisa ter acesso ao que foi feito.
Sobre infraestrutura e pós-entrega
11. "Onde vai rodar o sistema? A infraestrutura vai ficar no meu nome ou no de vocês?"
Infraestrutura deve estar na conta do cliente, não da software house. Se a empresa sair do ar ou houver conflito, você não pode perder acesso ao seu próprio sistema. Contas de AWS, Azure, GCP e domínios devem ser do cliente.
12. "O que está incluído no pós-entrega? Como funciona o suporte?"
"Período de garantia" de 30 dias não é suporte. Entenda exatamente o que acontece depois do go-live: quem vai fazer correções de bugs, qual é o SLA de resposta, e qual é o custo de manutenção contínua.
Sinais de alerta durante o processo comercial
Além das perguntas, fique atento a esses padrões:
- Proposta chegou em 24h para um projeto complexo: ninguém pensou sério sobre o escopo
- Preço muito abaixo do mercado: alguma coisa vai ser cortada — geralmente qualidade
- Não fizeram nenhuma pergunta sobre o seu negócio: não têm interesse real no problema
- Todo case é genérico, sem números: ou não têm cases reais ou não medem resultados
- Prometem prazo sem ver o escopo completo: o prazo vai mudar
Como comparar propostas de forma justa
Nunca compare preço isoladamente. Compare:
- Escopo detalhado — o que exatamente está incluído
- Premissas declaradas — o que pode mudar o preço
- Perfil real da equipe — quem vai trabalhar, não quem apresentou
- Qualidade técnica — testes, documentação, processo de deploy
- Referências verificáveis — clientes reais que você pode ligar
Uma proposta R$ 30 mil mais cara que entrega um sistema com testes, documentação e suporte real é mais barata do que uma proposta mais em conta que vai gerar R$ 200 mil em retrabalho em 18 meses.
O que fazer se você já está no meio de um projeto ruim
Se você chegou aqui porque está sofrendo com uma contratação em andamento, o protocolo é:
- Documente tudo por escrito (e-mail, não Whatsapp)
- Peça acesso imediato ao repositório de código
- Faça uma auditoria técnica independente do que foi entregue até agora
- Avalie com base no contrato o que é possível reclamar
- Planeje a transição com tempo — trocar de fornecedor no meio do projeto é difícil, mas possível
Avaliando propostas e não sabe por onde começar?
Oferecemos uma sessão de consultoria para ajudar gestores a avaliar propostas técnicas, identificar riscos e estruturar o escopo antes de contratar. Sem conflito de interesse — você decide com quem vai trabalhar.
Falar sobre avaliação de propostas →