20 perguntas para fazer antes de contratar uma software house

A reunião de briefing com uma software house é uma das etapas mais importantes do processo de contratação — e a maioria das pessoas a usa para apresentar o projeto, não para avaliar a empresa.

As perguntas certas revelam muito mais do que qualquer portfólio ou proposta comercial. Este guia reúne as 20 perguntas mais importantes, organizadas por tema.

Sobre portfólio e experiência

1. Vocês já desenvolveram algo parecido com o que preciso? Peça exemplos específicos — não cases genéricos. Uma empresa com experiência no seu tipo de projeto vai ter opiniões sobre como resolver o problema, não só sobre como executar o pedido.

2. Posso falar com algum cliente do portfólio? Empresas sérias não hesitam. Se houver resistência em fornecer referências, é um sinal de alerta.

3. O que aconteceu com os produtos que vocês desenvolveram? Eles estão em produção? Portfolios mostram o lançamento. O que importa saber é o que aconteceu depois — o produto escalou, teve problemas técnicos, precisou de refatoração completa?

4. Vocês têm experiência com o meu setor ou com o tipo de produto que quero construir? Software house para fintech tem desafios diferentes de software house para educação. Especialização setorial acelera o projeto e reduz risco.

Sobre processo e metodologia

5. Como funciona o processo de discovery de vocês? Essa pergunta separa empresas consultivas de empresas executoras. Uma resposta vaga sobre "entender as necessidades do cliente" sem metodologia clara indica que o discovery é superficial.

6. O que acontece quando o escopo muda no meio do projeto? A resposta revela a maturidade do processo de gestão de mudanças. Empresas que não têm processo definido para isso vão gerar atrito toda vez que você precisar ajustar algo.

7. Qual é a cadência de entregas e como funciona o acompanhamento do projeto? Sprints de duas semanas com demo? Reunião semanal de alinhamento? Daily assíncrono? A resposta mostra como você vai ter visibilidade do progresso sem precisar cobrar.

8. Como vocês lidam com bugs encontrados após a entrega? Qual é o período de garantia? O que está coberto? Bugs são resolvidos gratuitamente ou geram nova ordem de serviço? Isso precisa estar claro antes — não depois de encontrar o primeiro problema em produção.

Sobre o time

9. Quem vai trabalhar no meu projeto? Peça para conhecer o time antes de assinar. O time que ganhou o projeto é o mesmo que vai desenvolvê-lo? Qual é o seniority? Há dedicação exclusiva ou o time trabalha em múltiplos projetos simultaneamente?

10. Posso falar diretamente com os desenvolvedores durante o projeto? A resposta define o nível de acesso técnico que você vai ter. Em algumas empresas, todo contato passa pelo gerente de projeto — o que aumenta o ciclo de comunicação e o risco de ruído.

11. O que acontece se um membro do time sair durante o projeto? Rotatividade é uma realidade. Como a empresa garante continuidade de conhecimento? Qual é o prazo para substituição? Como é feita a transferência?

12. Qual é a proporção de desenvolvedores sênior, pleno e júnior no time proposto? Propostas que não especificam seniority merecem essa pergunta direta. A diferença de custo e produtividade entre níveis é significativa — e afeta o resultado final.

Sobre tecnologia

13. Qual stack vocês recomendam para o meu projeto e por quê? A justificativa importa tanto quanto a escolha. Uma empresa que recomenda a stack que ela conhece, independente do contexto, está otimizando para si — não para o seu projeto.

14. Como vocês garantem a qualidade do código? Code review? Testes automatizados? Cobertura mínima de testes? Empresas que não têm resposta clara para essa pergunta tendem a gerar dívida técnica.

15. O código vai ser entregue em repositório acessível para mim durante o projeto? Você deve ter acesso ao código em tempo real — não só na entrega final. Empresas que resistem a isso estão criando uma dependência artificial.

Sobre contrato e negócio

16. Qual é o modelo de contratação recomendado para o meu projeto e por quê? Projeto fechado, Time & Material ou squad dedicado — cada um tem implicações diferentes. A empresa deve conseguir explicar qual faz mais sentido para o seu contexto específico, não só oferecer o modelo que ela prefere vender.

17. Como são tratadas as mudanças de escopo no contrato? Existe um processo formal? Há um custo por avaliação de mudança? Como o impacto em prazo e custo é comunicado? Sem isso definido em contrato, cada mudança vira uma negociação.

18. Quem é o dono do código ao final do projeto? A resposta certa é: você. Verifique se o contrato deixa isso explícito — incluindo bibliotecas customizadas e assets desenvolvidos especificamente para o projeto.

19. O que está fora do escopo desta proposta? Tão importante quanto o que está incluído. Infraestrutura, publicação nas lojas, treinamento, manutenção pós-lançamento — muitos custos "surpresa" na contratação de software houses são itens que simplesmente não foram mencionados na proposta.

20. Por que eu deveria contratar vocês e não outra empresa? Uma pergunta direta que revela autoconhecimento. A resposta ideal não é "somos os melhores" — é uma articulação clara de onde a empresa tem vantagem real para o seu tipo de projeto.

Como usar essas perguntas

Não é necessário fazer todas as 20 em uma única reunião. Organize por prioridade para o seu contexto:

Se você ainda está em fase de seleção inicial, foque nas perguntas de portfólio e processo (1 a 8).

Se já está em fase de negociação com uma ou duas empresas, aprofunde nas perguntas sobre time e contrato (9 a 20).

Guarde as respostas de cada empresa — a comparação entre elas costuma ser mais reveladora do que qualquer proposta.

Perguntas frequentes

Fazer muitas perguntas vai parecer desconfiança? Não para empresas sérias. Uma software house madura reconhece que perguntas detalhadas indicam um cliente que entende o processo — o que facilita a relação, não dificulta. Se a empresa ficou na defensiva com perguntas básicas, é um sinal importante sobre como vai ser a comunicação durante o projeto.

E se a empresa não souber responder alguma pergunta? Depende da pergunta. Não saber o preço exato antes de um discovery é aceitável. Não saber quem vai trabalhar no projeto ou não ter política de garantia são lacunas mais preocupantes.

Devo enviar essas perguntas antes da reunião? Para perguntas sobre portfólio e processo, enviar com antecedência permite respostas mais elaboradas. Para perguntas sobre time e negócio, a reunião presencial (ou por vídeo) revela mais — inclusive na linguagem não-verbal.

Compare as respostas de diferentes software houses usando os perfis verificados do Softdex — e entre nas reuniões já com contexto sobre cada empresa.