Como escolher uma software house: 8 critérios que importam

Escolher uma software house é uma decisão que a maioria toma pelo preço — e é aí que o projeto começa a dar errado. O parceiro certo entrega um sistema que roda e cresce; o errado entrega uma promessa, alguns boletos e um código que você nem sabe se pode levar embora.

Não é drama de vendedor. O CHAOS Report do Standish Group, que acompanha mais de 50 mil projetos de software, aponta que cerca de 19% são cancelados e 52% terminam "desafiados" — atrasados, acima do orçamento ou sem parte do que foi combinado. Só cerca de 29% chegam ao fim como planejado. E o tamanho pesa: projetos pequenos passam de 90% de sucesso, enquanto os muito grandes ficam abaixo de 10%. Quem você contrata muda esse número mais do que qualquer tecnologia.

Por que a escolha do parceiro decide o projeto

As maiores causas de fracasso não são técnicas. Ainda segundo o levantamento do Standish, os campeões são requisito mal definido (citado em 39% dos casos) e escopo que incha no meio do caminho (33%). Ou seja: o problema quase sempre é processo e comunicação, não a linguagem de programação. Uma software house boa se distingue justamente por como ela conduz essas duas coisas antes de escrever a primeira linha.

O que quase nenhum guia sobre software house te conta

Pesquise "como escolher software house" e você vai ler sempre a mesma lista: veja o portfólio, leia avaliações, confira a metodologia. Tudo válido — e tudo insuficiente. O que derruba empresas depois da entrega não aparece nesses artigos: de quem é o código, quem controla a infraestrutura e como o contrato trata mudança de escopo. É onde a conta chega quando você menos espera.

De quem é o código que você paga para desenvolver?

Parece óbvio que o código é seu porque você pagou por ele. Não é. Na maioria das legislações de direito autoral, quem escreve o código detém a propriedade por padrão — a menos que exista uma cláusula explícita de cessão de propriedade intelectual transferindo tudo para você. Sem esse parágrafo no contrato, você comprou o direito de usar, não de possuir.

Pior é o cenário de aprisão por fornecedor (o vendor lock-in): o repositório fica na conta da software house, os servidores de produção rodam na nuvem dela e as chaves de API estão no e-mail dela. No dia em que você quiser trocar de parceiro, a migração vira negociação de refém. A boa prática é o contrário disso — repositório no seu nome desde o primeiro dia, contas de nuvem e domínio registradas em nome da sua empresa, e cessão de PI revisada antes de assinar.

Checklist de posse antes de assinar

• Repositório de código (GitHub, GitLab) criado na conta da sua empresa, com a software house como colaboradora — nunca o contrário.
• Contas de nuvem, banco de dados e domínio registradas no seu nome e cartão, não no do fornecedor.
• Cláusula de cessão total de propriedade intelectual do código, do design e da documentação — leia se o contrato dá posse ou apenas licença de uso.
• Credenciais e chaves de integração (gateways, APIs, e-mail) sob e-mails da sua empresa.
• Direito a receber o código-fonte e a documentação em qualquer encerramento, sem cláusula que trave a entrega.

Esse cuidado não é desconfiança gratuita: é o que garante que um sistema sob medida continue seu mesmo que a parceria acabe. Uma software house séria oferece isso de bom grado — quem trava, está te dizendo algo.

Preço fechado ou por hora: qual protege seu bolso

Preço fechado transmite segurança, mas tem um custo escondido. Para assumir o risco de um escopo incerto, o fornecedor embute uma gordura de segurança que, segundo consultorias do setor como a Baytech, costuma inflar o valor em 15% a 30% — e você paga esse prêmio mesmo que o imprevisto nunca aconteça. Há inclusive estudo citado nesses materiais indicando que contratos de preço fechado se associam a maior risco de fracasso do que os por tempo e material, porque engessam mudanças que quase sempre são necessárias.

A regra prática: escopo fechado funciona bem para entregas pequenas e muito bem definidas, como uma landing page ou um módulo isolado. Para um produto que vai evoluir — um SaaS, um sistema de gestão —, o modelo por hora ou por sprint dá transparência do que está sendo feito e liberdade para ajustar rota sem renegociar o contrato inteiro a cada ideia nova.

8 critérios para avaliar uma software house

Junte tudo numa avaliação objetiva. Antes de fechar, passe cada candidata por estes oito pontos, em ordem de peso:

• Portfólio com casos parecidos com o seu — não só bonitos, mas do seu porte e setor, com resultado que dá para checar.
• Reputação verificável em plataformas independentes como Clutch e G2, além de conversar com um cliente atual da empresa.
• Posse do código e da infraestrutura garantidas em contrato, conforme o checklist acima.
• Modelo de cobrança compatível com o seu tipo de projeto (fechado para escopo curto, por sprint para produto que cresce).
• Metodologia ágil de verdade: entregas em ciclos curtos que você vê rodando, não um único "big bang" no fim.
• Time nomeado — quem são as pessoas, se são internas ou terceirizadas, e o que acontece se alguém sair (o famoso fator ônibus).
• Cadência de comunicação clara: com que frequência você recebe atualização e por qual canal.
• Suporte e manutenção após a entrega, com prazo de resposta definido — software não termina no lançamento.

Dá para testar boa parte disso já na primeira conversa. Pergunte: "o repositório fica no meu nome?", "como vocês tratam mudança de escopo?" e "quem dá manutenção depois?". As respostas — e a rapidez delas — dizem mais sobre o parceiro do que qualquer proposta comercial caprichada.

O que acontece depois da entrega

Sistema é organismo vivo: precisa de correção, atualização de dependência e ajuste conforme o negócio muda. Muita gente descobre tarde que contratou desenvolvimento, mas não manutenção — e fica refém de quem construiu. Alinhe desde o começo como será o suporte, e prefira quem já pensa a arquitetura para durar, seja num SaaS multi-inquilino ou nas integrações via API que ligam seu sistema ao resto da operação.

A pergunta certa não é "quanto custa o sistema", e sim "o que sobra comigo quando a parceria acabar". Se a resposta for o código, a infraestrutura e a autonomia, você escolheu bem.

Se você está prestes a contratar e ainda tem dúvida sobre escopo, posse de código ou modelo de cobrança, a VELTRIX faz um diagnóstico gratuito: a gente olha o que você precisa, aponta os riscos do contrato e mostra o caminho mais curto até um sistema que fica seu de verdade — sem compromisso de fechar nada.