Como escolher uma software house no Brasil: o que perguntar antes de assinar

A maioria das empresas erra na escolha. E o erro custa caro.

Segundo dados da Associação Brasileira de Empresas de Software (ABES), o Brasil tem mais de 23.000 empresas que se classificam como "desenvolvedoras de software". Dessas, estima-se que menos de 3.000 mantenham equipes técnicas estáveis com mais de 10 desenvolvedores. O resto são consultorias individuais, freelancers PJ ou empresas que montam equipe sob demanda a cada projeto.

Isso não é necessariamente ruim. Mas significa que a distância entre uma software house profissional e uma operação improvisada é enorme. E a consequência de escolher errado geralmente aparece 4 a 6 meses depois do contrato, quando o projeto está atrasado, acima do orçamento e com qualidade questionável.

Depois de anos entregando projetos na Bradata (e também observando projetos que chegaram até nós depois de fracassarem em outros fornecedores), compilei o que realmente importa na hora de escolher.

Red flags que eliminam na hora

Antes de avaliar qualidade, elimine quem apresenta esses sinais:

Sem código próprio visível. Se a empresa não tem nem um blog técnico, nem contribuições open-source, nem cases com detalhamento arquitetural, desconfie. Qualquer empresa séria tem pelo menos um artigo explicando como resolveu um problema técnico real.

Proposta em 48 horas para projeto complexo. Se você descreveu um ERP com 8 módulos e recebeu uma proposta detalhada em dois dias, essa proposta foi feita por alguém que não entendeu a complexidade ou que está chutando. Projetos complexos exigem discovery. Fuja de quem pula essa etapa.

Time 100% terceirizado. Pergunte diretamente: "Os desenvolvedores que vão trabalhar no meu projeto são CLT de vocês ou freelancers?" Se a resposta for evasiva, o risco de turnover no meio do projeto é alto. Não é que freelancer não funcione. Mas o modelo precisa ser transparente.

Nenhuma menção a testes ou CI/CD. Se na proposta não aparece nada sobre cobertura de testes, pipeline de deploy, code review, a empresa provavelmente não pratica engenharia de software. Pratica codificação.

Portfólio só com logos, sem detalhes. "Trabalhamos com empresa X" não significa nada se você não sabe o que foi feito, qual o tamanho do time, quanto durou, que tecnologias foram usadas.

Os red flags menos óbvios (e mais perigosos)

Os sinais acima qualquer comprador atento percebe. Os que quebram projeto de verdade são mais sutis, porque aparecem depois que o contrato já foi assinado.

O comercial promete, o time desconhece. Você fecha o projeto com um vendedor cheio de energia e, na primeira reunião técnica, descobre que o time nunca ouviu falar das funcionalidades que foram prometidas. Peça para colocar quem vai executar na sala antes de assinar. Se o discurso do vendedor e do tech lead não bate, o problema já começou.

Estimativa sem faixa de incerteza. Software house madura fala em faixas ("entre 14 e 18 semanas, com risco maior na integração com a SEFAZ"). Quem crava "12 semanas exatas" para um projeto que ainda nem passou por discovery está vendendo certeza que não existe. Em software, cerca de 60% dos projetos estouram o prazo original segundo o Standish Group. Quem finge que isso não existe vai te surpreender no meio do caminho.

Documentação tratada como custo, não como entrega. Pergunte o que fica com você além do código. Se a resposta não inclui documentação de arquitetura, README de setup e um guia de deploy, você vai ficar refém do fornecedor para qualquer mudança futura.

Resposta lenta na fase de namoro. Se leva três dias para responder um e-mail agora, quando está tentando fechar contrato, imagine quando você for só mais um cliente na carteira. A velocidade de resposta na fase comercial é o melhor previsor do suporte que você vai receber depois.

Scorecard: como pontuar cada fornecedor

Comparar "no feeling" é como o mercado erra. Monte uma planilha simples e pontue cada fornecedor de 1 a 5 em cada critério, com pesos. Este é o modelo que recomendo:

Critério	Peso	O que nota 5 significa
Time fixo e senioridade real	25%	Devs CLT/sócios, proporção sênior saudável, você conversou com quem vai executar
Cases no seu domínio	20%	Três projetos parecidos, com cliente disposto a dar referência
Processo de engenharia	15%	CI/CD, testes automatizados, code review descritos com clareza
Turnover baixo	15%	Abaixo de 15% ao ano, comprovável
Modelo de contrato adequado	10%	Sugerem o modelo que protege você, não o que maximiza a margem deles
Transparência de preço	10%	Orçamento aberto, sem "extras" surpresa, faixa de incerteza explícita
Suporte pós-entrega	5%	Contrato de manutenção claro, SLA definido

Multiplique nota por peso, some e você tem um número comparável entre fornecedores. Não é ciência exata, mas força você a olhar para o que importa em vez de se encantar com o slide de abertura. Um fornecedor que passa de 4,0 na média ponderada raramente decepciona. Abaixo de 3,0, o risco não compensa nenhum desconto.

As 10 perguntas que você deveria fazer

Na reunião de avaliação, estas perguntas revelam mais do que qualquer apresentação comercial:

1. Qual o tamanho do time fixo? Não contratados, fixo. CLT ou sócios que vão estar lá mês que vem.
2. Podem me mostrar o código de um projeto (com autorização do cliente)? Ou pelo menos a arquitetura. Se nunca mostraram código para ninguém, por que não?
3. Como funciona a fase de discovery? Se não existe, próximo.
4. Qual o turnover do time nos últimos 12 meses? Alta rotatividade significa que quem começou seu projeto provavelmente não vai terminar.
5. Quantos projetos simultâneos o time toca? Se são 5 devs tocando 8 projetos, a conta não fecha.
6. Qual a stack padrão? Empresas maduras têm opinião sobre tecnologia. "Fazemos qualquer coisa" geralmente significa "não somos especialistas em nada".
7. Como é o deploy? Manual por FTP? Docker com CI/CD? Kubernetes? A resposta revela a maturidade operacional.
8. O que acontece se o projeto atrasar? A resposta precisa ser contratual, não verbal.
9. Posso falar com um cliente anterior? Se a resposta for não, red flag imediato.
10. Vocês fazem manutenção pós-entrega? Quanto custa? Muitas software houses entregam e somem. O custo de manutenção precisa estar no planejamento desde o dia zero.

Modelos de contrato: escopo fechado vs. squad dedicado

Essa é a decisão mais importante depois de escolher o fornecedor.

Escopo fechado (preço fixo)

Você define o que quer. A software house estima o esforço, dá um preço e um prazo. Se der mais trabalho do que o previsto, o risco é dela.

Funciona quando:

• O escopo está muito bem definido (wireframes prontos, regras de negócio documentadas)
• O projeto é de tamanho pequeno a médio (até 4 meses)
• Você não pretende mudar requisitos durante o desenvolvimento

Não funciona quando:

• Você ainda está descobrindo o produto
• O projeto é longo (6+ meses) e vai mudar
• Há integrações com sistemas legados cujo comportamento ninguém documenta

O risco escondido do escopo fechado: a software house vai entregar exatamente o que está escrito. Se o documento de escopo estiver incompleto (e quase sempre está), você vai receber um software tecnicamente correto mas funcionalmente insuficiente.

Squad dedicado (time alocado)

Você contrata um time (ou parte de um) por mês. Geralmente 1 a 4 devs, 1 PM, designer conforme necessidade. O escopo é flexível, as entregas são incrementais.

Funciona quando:

• O produto está em evolução contínua
• Você precisa de velocidade para pivotar
• O projeto é de longo prazo (6+ meses)

Não funciona quando:

• Você não tem alguém do seu lado para priorizar e validar entregas semanalmente
• O orçamento é fixo e não admite variação
• Você quer "contratar e esquecer"

Na Bradata, trabalhamos com ambos os modelos dependendo do perfil do projeto. Para MVPs com escopo claro, escopo fechado funciona bem. Para plataformas SaaS em evolução, squad dedicado é quase sempre a melhor escolha. O ponto chave: o modelo precisa ser honesto sobre onde está o risco.

Modelo híbrido

Começar com escopo fechado para o MVP (3 meses) e migrar para squad dedicado para evolução contínua. Esse modelo reduz o risco inicial e permite avaliar a qualidade da entrega antes de comprometer orçamento de longo prazo.

Como avaliar o portfólio de verdade

Não olhe só para o visual. Um site bonito pode esconder uma arquitetura frágil. O que realmente importa:

Pergunte sobre decisões técnicas. "Por que usaram Next.js em vez de React puro?" Se a resposta for "porque é o que a gente usa", preocupe-se. Se for "porque o projeto precisava de SSR para SEO e ISR para performance com conteúdo dinâmico", a equipe pensa antes de codar.

Verifique se os projetos entregues ainda estão no ar. Um portfólio cheio de projetos que não existem mais levanta dúvidas.

Peça métricas. Tempo de entrega versus estimativa. Quantidade de bugs em produção nos primeiros 30 dias. Uptime. Software houses maduras medem essas coisas. As que não medem não sabem se estão entregando bem ou não.

Olhe a diversidade dos projetos. Uma empresa que só fez sites institucionais provavelmente vai sofrer para entregar um ERP. Experiência em domínios complexos (fiscal, saúde, logística) indica capacidade de lidar com regras de negócio difíceis. Se o seu projeto é um ERP sob medida, procure quem já lidou com integração fiscal e workflows de aprovação, não quem só fez landing pages.

Cláusulas de contrato que você precisa checar antes de assinar

O contrato é onde as promessas viram obrigação. A maioria dos compradores lê o preço e o prazo e ignora o resto. Foque nestas cláusulas:

Propriedade intelectual e código-fonte. O contrato precisa dizer, com todas as letras, que todo o código produzido é seu, incluindo bibliotecas internas desenvolvidas durante o projeto. Cuidado com a expressão "licença de uso": você não quer licenciar o seu próprio software, você quer ser dono dele.

Acesso ao repositório desde o commit zero. Exija que o código fique num repositório sob a sua conta (ou com acesso de administrador garantido) desde o primeiro dia. Fornecedor que só entrega o código no final está segurando um refém.

Cláusula de reversão e transição. O que acontece quando o contrato termina? Um bom contrato prevê um período de transição (30 a 60 dias) com repasse de documentação e knowledge transfer para a sua equipe ou para o próximo fornecedor. Sem isso, trocar de parceiro vira um pesadelo.

Definição de "pronto". Sem critério de aceite escrito, "entregue" vira uma discussão sem fim. O contrato deve amarrar entrega a critérios objetivos: passa nos testes, roda em produção, atende aos casos de uso descritos.

Responsabilidade por atraso. Verbal não vale. O contrato precisa dizer o que acontece se o fornecedor atrasar por culpa dele: desconto, multa ou horas adicionais sem custo. Igualmente, precisa proteger o fornecedor quando o atraso vier de mudança de escopo sua.

Confidencialidade e LGPD. Se o time vai tocar dados dos seus clientes, o contrato precisa de cláusula de proteção de dados e um acordo de tratamento coerente com a LGPD. Isso não é burocracia, é o que te protege de uma multa da ANPD.

Garantia pós-entrega. Quanto tempo de correção de bugs sem custo você tem depois de aceitar a entrega? Trinta dias é o mínimo razoável. Noventa é o ideal para sistemas críticos.

Perguntas que mudam conforme o tipo de projeto

As dez perguntas gerais valem para tudo. Mas cada tipo de projeto tem armadilhas próprias.

Se é um ERP ou sistema de gestão: pergunte sobre experiência com integração fiscal (SEFAZ, NF-e, SPED), controle de permissões por perfil e migração de dados do sistema antigo. A migração de dados costuma ser 20 a 30% do esforço e quase nunca aparece na proposta inicial. Vale entender como funciona um ERP sob medida antes de fechar escopo.

Se é um produto SaaS multi-tenant: pergunte como resolvem isolamento de dados entre clientes, billing recorrente e escalabilidade. Um erro de arquitetura em multi-tenancy é caríssimo de corrigir depois.

Se é um app mobile: pergunte se é nativo, híbrido ou React Native, e por quê. Pergunte também quem cuida das publicações nas lojas e das atualizações forçadas quando o iOS ou Android muda as regras.

Se você precisa de reforço no seu time interno: o modelo pode não ser projeto fechado, e sim alocação de talentos ou staff augmentation. Nesse caso, as perguntas mudam: senioridade individual, fit cultural, tempo de rampa e como funciona a substituição se um profissional não engatar.

Preço baixo demais é o risco mais caro

Se você recebeu três orçamentos e um deles é 40% mais barato que os outros dois, esse fornecedor provavelmente está subestimando o escopo, vai usar profissionais juniores ou vai cobrar "extras" durante o projeto.

A faixa de preço razoável para um squad de 3 devs + PM + designer no Brasil em 2026 fica entre R$ 45.000 e R$ 85.000 por mês, dependendo da senioridade e da região. Valores muito abaixo disso significam que alguém está subsidiando o projeto com trabalho subvalorizado. E trabalho subvalorizado gera rotatividade.

O que fazer antes de contratar

1. Defina o problema antes de definir a solução. "Preciso de um app" não é briefing. "Meus vendedores externos perdem 2 horas por dia preenchendo relatórios em papel" é.
2. Fale com pelo menos 3 fornecedores. Compare não só preço, mas processo e profundidade das perguntas que eles fazem na reunião.
3. Exija uma fase de discovery antes de começar o desenvolvimento. 2 a 4 semanas. Pode custar entre R$ 8.000 e R$ 25.000. É o melhor investimento que você vai fazer.
4. Leia o contrato inteiro. Especialmente as cláusulas sobre propriedade intelectual, código-fonte e rescisão.
5. Peça acesso ao repositório desde o dia 1. O código é seu. Se a software house não quer mostrar o código durante o projeto, algo está errado.

Escolher uma software house é uma decisão de risco, não apenas de preço. Faça a due diligence como faria ao contratar um CFO. O impacto no seu negócio é comparável.

Perguntas frequentes

Quanto tempo leva para escolher uma software house? Do primeiro contato à assinatura, um processo bem feito leva de 3 a 6 semanas. Isso inclui falar com pelo menos três fornecedores, uma fase de discovery ou pré-projeto e a revisão do contrato. Quem fecha em uma semana geralmente pula etapas que vão cobrar caro depois.

Vale mais a pena contratar uma software house grande ou pequena? Depende do projeto. Empresas grandes têm mais estrutura e processos, mas você pode virar um cliente pequeno na carteira, com o time B tocando o seu projeto. Empresas menores dão mais atenção e senioridade direta, mas têm menos folga para absorver uma saída de profissional. O que importa não é o tamanho, é quem exatamente vai executar o seu projeto e quão estável é esse time. Entenda como uma software house monta os squads antes de decidir pelo porte.

Posso contratar um freelancer em vez de uma software house? Para tarefas pontuais e bem delimitadas, sim. Para um produto que vai crescer e precisa de manutenção contínua, o risco é alto: se o freelancer some, você fica com um código que só ele entende. Software house oferece continuidade, processo e substituição de profissionais. O custo maior compra redução de risco.

O que é uma fase de discovery e por que ela custa? Discovery é o período (2 a 4 semanas) em que o fornecedor mapeia o seu problema, define escopo, desenha arquitetura e estima esforço com base em fatos, não em chute. Custa entre R$ 8.000 e R$ 25.000 porque envolve seniores dedicados. É o melhor seguro contra o orçamento estourar depois.

Como sei se o preço está justo? Peça três orçamentos e compare a estrutura, não só o número final. Um squad de 3 devs mais PM e designer no Brasil em 2026 custa entre R$ 45.000 e R$ 85.000 por mês. Preço muito abaixo disso significa que alguém está subsidiando com trabalho subvalorizado, e isso gera rotatividade no meio do seu projeto.

Se você já tem um projeto na mesa e quer uma segunda opinião honesta sobre escopo e viabilidade, fale com a gente. Preferimos dizer "não construa isso ainda" a vender um projeto que não vai gerar retorno.