Resumo em 30 segundos
- Para escolher uma software house, avalie nove pontos: problema, portfólio, escopo, equipe, processo, segurança, propriedade do código, suporte e preço.
- Peça evidência, não promessa: demo, contrato, exemplos de entrega e referências que você possa ligar.
- O menor preço quase nunca é o melhor negócio. O que pesa é o custo total, incluindo mudanças e manutenção.
- Sem cláusula de propriedade intelectual e acesso ao repositório, você corre risco de lock-in.
- Demo semanal é a forma mais simples de detectar atraso cedo.
- Sinal de alerta: proposta que promete tudo, sem dizer o que fica de fora.
Este artigo é um checklist. Ele não repete o panorama do mercado: para isso, leia o guia Software house: o que faz e como contratar a certa. Aqui o foco é prático: o que verificar, que pergunta fazer na reunião e qual resposta deve acender o alerta.
Como escolher uma software house na prática?
Para escolher uma software house, compare fornecedores com os mesmos nove critérios e peça evidência de cada um. Pontue as respostas de 0 a 2 depois de cada reunião. Assim a decisão deixa de depender de simpatia ou de preço e passa a refletir risco real, responsabilidade e capacidade de entrega.
A tabela abaixo resume os critérios. Ela serve como roteiro para a reunião e como matriz de comparação entre propostas.
A conclusão da tabela: os critérios 3, 7 e 8 (escopo, propriedade e suporte) são os que mais geram disputa depois da assinatura.
| # | Critério | Pergunta-chave | Sinal de alerta |
|---|---|---|---|
| 1 | Diagnóstico | Que perguntas vocês fazem antes de orçar? | Orça em 24 horas sem entender o processo |
| 2 | Portfólio | Qual projeto parecido com o meu vocês entregaram? | Só mostra telas bonitas |
| 3 | Escopo | O que está fora do escopo? | Escopo vago ou “tudo incluso” |
| 4 | Equipe | Quem escreve o código e como falo com essa pessoa? | Só o comercial atende |
| 5 | Processo | Há demo semanal e critério de aceite? | Só mostra o produto no fim |
| 6 | Segurança | Como tratam a LGPD, logs e backup? | Não sabe responder |
| 7 | Propriedade | De quem é o código, o dado e a infraestrutura? | Cláusula omissa ou repositório do fornecedor |
| 8 | Suporte | O que acontece após o lançamento? | Contrato termina na entrega |
| 9 | Preço | O que muda o valor durante o projeto? | Preço muito abaixo dos demais |
1. Ela começa pelo problema ou pela tecnologia?
Uma boa software house começa pelo problema, não pela stack. Antes de falar de React, Python ou nuvem, ela pergunta quem usa o sistema, qual trabalho manual existe hoje e o que acontece quando algo falha. Conversa que pula direto para tecnologia tende a virar lista de telas.
Exemplo da rotina de engenharia: um escritório quer automatizar orçamentos. O fornecedor certo pergunta de onde vêm as composições de custo, quem revisa o valor final e quem assina a responsabilidade técnica. O errado pergunta apenas “quantas telas?”.
Pergunte na reunião: “O que vocês precisam saber sobre a minha operação antes de passar um preço?”
2. O que avaliar no portfólio?
No portfólio, avalie a semelhança com o seu desafio, não a quantidade de logos. Verifique se o projeto está no ar, qual problema resolveu e se há um cliente disposto a conversar. Telas bonitas provam design, não capacidade de sustentar um sistema em produção.
- Peça um caso com complexidade parecida: integrações, regras de negócio, perfis de acesso.
- Pergunte o que deu errado e como foi corrigido. Quem nunca errou não tem experiência.
- Peça uma referência para ligar. Dois telefonemas valem mais que dez páginas de portfólio.
- Confira se o produto ainda funciona: abra o link, teste o aplicativo.
3. O escopo está claro, inclusive o que fica de fora?
Escopo fechado é o acordo escrito do que será entregue, em qual prazo e por qual preço. Ele protege os dois lados quando lista também o que está fora e define critérios de aceite. Sem isso, cada pedido novo vira discussão sobre quem paga.
Exija na proposta:
- Lista de funcionalidades da primeira versão.
- Lista do que fica para depois.
- Critérios de aceite por entrega, em linguagem que você entenda.
- Regra para mudanças: como são estimadas e aprovadas.
Escopo fechado não significa engessado. Significa que toda mudança passa por um acordo explícito. Se o produto ainda é uma hipótese, valide primeiro com um MVP: veja como criar um MVP de software, da ideia ao lançamento.
4. Com quem você fala: com quem escreve o código?
Avalie quem de fato trabalha no seu projeto. Em muitas empresas, quem vende não é quem desenvolve, e a informação se perde no caminho. Contato direto com quem escreve o código reduz ruído, acelera decisões e deixa claro quem responde por cada entrega.
Pergunte: “Quem vai desenvolver? Posso conversar com essa pessoa antes de assinar?”
Desconfie de resposta como “nossa equipe cuida de tudo”, sem nomes, senioridade ou papéis. Veja também se o time é próprio ou terceirizado em cadeia, o que adiciona camadas entre você e o código.
5. Vale exigir demo semanal?
Sim. Demo semanal é uma apresentação curta, toda semana, do software funcionando, não de slides. Ela mostra progresso real, expõe mal-entendidos cedo e permite corrigir a rota quando o custo de mudar ainda é baixo. Fornecedor que resiste a mostrar o produto costuma ter algo a esconder.
O que observar no processo:
- Demo em ambiente real ou de homologação, não em protótipo estático.
- Registro das decisões tomadas em cada reunião.
- Backlog visível, com prioridades que você pode ajustar.
- Entregas pequenas e frequentes em vez de uma grande entrega no fim.
6. Como ela trata segurança e LGPD?
Segurança precisa entrar no desenho do produto, não no fim. A Lei Geral de Proteção de Dados (Lei 13.709/2018, LGPD) obriga quem trata dados pessoais a adotar medidas técnicas e administrativas de proteção. Pergunte como o fornecedor lida com permissões, logs, backup e dados sensíveis.
Em sistemas com IA, vá além: quais dados vão para o modelo, onde ficam armazenados e quem revisa o resultado. Para engenharia, isso inclui projetos de clientes sob sigilo e a responsabilidade técnica registrada por ART no sistema Confea/CREA. IA apoia, mas a revisão e a assinatura continuam humanas.
Pergunte: “Quais dados nossos o sistema vai guardar e quem tem acesso a eles?”
7. Como conferir a propriedade do código?
Confira a propriedade do código lendo o contrato e pedindo acesso ao repositório desde o início. O contrato deve dizer que código, dados e propriedade intelectual pertencem ao cliente. Lock-in é a dependência que impede você de trocar de fornecedor sem perder o sistema.
Checklist rápido de propriedade:
- O contrato cede a propriedade intelectual do código ao cliente?
- O repositório fica numa conta sua ou com acesso integral para você?
- A infraestrutura (nuvem, domínios, chaves) está em seu nome?
- Há documentação suficiente para outra equipe assumir?
- Bibliotecas proprietárias do fornecedor estão listadas, com licença?
Se qualquer resposta for “depois a gente vê”, trate como alerta. Para decidir entre terceirizar ou montar equipe, leia software house ou time interno: qual vale mais.
8. O que acontece depois do lançamento?
Software não termina quando vai ao ar. Usuários mudam, regras mudam e integrações quebram. A proposta deve dizer quem corrige falhas, em quanto tempo, quanto custa a evolução e como funciona o monitoramento. Contratar só a primeira entrega costuma sair caro depois.
Pergunte: “Se o sistema cair numa segunda-feira, quem atende e em quanto tempo?”
Verifique também se a hospedagem e a arquitetura aguentam o crescimento. Um bom ponto de partida é entender como funciona uma arquitetura de nuvem e infraestrutura escalável.
9. O preço faz sentido?
O preço faz sentido quando você entende o que ele inclui e o que o faz mudar. A proposta mais barata costuma omitir testes, documentação, suporte ou integrações, que reaparecem depois como aditivos. Compare o custo total, não o valor da primeira parcela.
Preço, prazo e escopo precisam caber numa página só, legível por quem não é técnico. Para entender as faixas e o que as influencia, veja quanto custa desenvolver um software sob medida.
Quais sinais de alerta exigem cautela?
Os principais sinais de alerta são: promessa sem priorização, orçamento sem diagnóstico, silêncio sobre manutenção, contrato omisso sobre propriedade e resistência a mostrar o produto funcionando. Um sinal isolado pede esclarecimento. Três ou mais pedem que você procure outro fornecedor.
- Prazo e preço fechados em uma conversa, sem perguntas sobre o seu processo.
- Portfólio sem nenhum cliente disposto a dar referência.
- Equipe que só aparece depois da assinatura.
- Código mantido em conta do fornecedor, sem acesso para você.
- Argumento de IA como enfeite comercial, sem tarefa, dado ou controle definidos.
Quais erros evitar ao contratar uma software house?
Os erros mais comuns são comparar só preço e prazo, aceitar escopo sem critério de aceite, deixar a propriedade do código para depois, não envolver os usuários finais e tratar a contratação como compra fechada. Todos têm remédio simples: perguntar mais cedo e registrar por escrito.
Como montar a decisão final
Monte uma matriz com os nove critérios nas linhas e os fornecedores nas colunas. Dê nota de 0 a 2 a cada resposta e some. Desempate pela transparência: quem respondeu com exemplo concreto merece mais confiança que quem respondeu com adjetivo. Se precisar de contexto, leia o que é software house e como ela trabalha.
Conclusão
Escolher bem é reduzir surpresa. Os pontos principais:
- Comece pelo problema, não pela tecnologia.
- Avalie o portfólio por semelhança e referência.
- Feche escopo, fora de escopo e critérios de aceite.
- Exija demo semanal e contato direto com quem programa.
- Garanta por contrato a propriedade do código, dos dados e da infraestrutura.
- Planeje o suporte e compare o custo total.
Se quiser aplicar este checklist ao seu projeto, a Hize faz um discovery em duas semanas, com escopo, prazo e preço numa página só. Veja como funciona o desenvolvimento de produto digital sob medida e fale com quem escreve o código.
Perguntas frequentes
As respostas curtas estão na seção de FAQ ao final desta página.