Software house: quando contratar (e quando não) — o guia do fundador não-técnico

A primeira vez que falei com um fundador que tinha sido queimado por uma software house, ele me mostrou um repositório com 11 mil arquivos, sem README, sem testes, e três commits do tipo final-final.zip. A empresa que tinha entregue aquilo já não respondia mensagens há quatro meses. Ele tinha pago R$ 320 mil. Tinha um sistema que rodava. Quase. E não tinha mais ninguém que soubesse mexer.

A pergunta que ele me fez, e que aparece em alguma versão em quase toda primeira reunião com fundadores não-técnicos, foi essa: “vale a pena contratar uma software house, ou eu deveria ter feito diferente?”

Vale, na maioria dos casos. Mas a pergunta está mal formulada. Software house não é uma escolha contra freelancer ou contra time interno. É uma das quatro opções reais que um fundador tem para construir software, e cada uma faz sentido em momentos específicos. O erro que custou R$ 320 mil ao fundador acima não foi escolher software house. Foi escolher aquela software house pelos motivos errados.

Este guia descreve como decidir, e como decidir bem.

O que é uma software house, na prática

Uma software house é uma empresa especializada em projetar e construir software sob medida para outras empresas. A versão curta: um time multidisciplinar (produto, design, engenharia) que entrega um sistema funcionando, da concepção até o deploy, sem que a contratante precise montar um time de tecnologia interno.

Na prática, o que distingue uma software house de outras formas de contratar engenharia é o escopo da entrega. Uma software house entrega o produto. Um freelancer entrega horas. Um time interno entrega um time. As três coisas custam dinheiro de jeitos diferentes, exigem gestão diferente e produzem resultados diferentes.

Esse “entrega o produto” não é trivial. Significa que a software house é responsável pelo pacote completo: spec, decisões de arquitetura, código, QA, infraestrutura, e a documentação que permite que alguém continue o trabalho depois. Quando a entrega é boa, o fundador termina o projeto com um sistema rodando, um repositório legível, e a opção real de internalizar o time depois. Quando é ruim, termina com 11 mil arquivos sem dono.

As quatro opções reais (e o que cada uma faz bem)

Antes de decidir contratar uma software house, vale colocar as quatro opções que você realmente tem em cima da mesa. Cada uma resolve um conjunto de problemas e cria outro.

No-code. Bubble, Glide, Softr, Retool. Útil para validar uma ideia antes de pagar engenharia de verdade. Quebra na primeira customização que o roadmap do fornecedor não previu. Tem teto. A maioria dos fundadores fica seis a doze meses a mais do que devia.

Freelancer ou dev solo. Barato na hora, caro no acumulado. Excelente para um pedaço pequeno e bem definido (um conector, um script, uma feature isolada). Péssimo para construir um produto inteiro: sem revisão de código, sem redundância, sem ninguém para discutir trade-offs de arquitetura. Se o dev sai, o sistema fica órfão.

Time interno (CTO + dois ou três engenheiros). O melhor caminho quando o software é o negócio e a empresa tem maturidade para gerir engenharia. Caro de montar, lento de ramping, difícil de gerir se você não vem da área. Se a empresa não atingiu o estágio em que software é vantagem competitiva real, é cedo demais.

Software house. Entrega o produto e a documentação. Ramping rápido (semanas, não meses). Caro por hora, mas o custo total costuma ser menor que o time interno equivalente até a Series A, porque você só paga a banda que está usando. O risco é depender de fornecedor para um ativo central; o jeito de mitigar isso está no contrato e na escolha de quem você contrata, e os dois assuntos têm seção própria mais à frente.

A regra que segue é prática: quanto mais o sistema é central para o negócio e quanto mais ele vai mudar nos próximos doze meses, mais a balança pesa para time interno. Quanto mais o sistema é complementar e quanto mais o fundador precisa preservar foco em outras frentes (vendas, fundraising, regulação), mais ela pesa para software house. Freelancer só ganha em recortes pequenos. No-code só ganha em validação.

O framework de quatro perguntas

Eu uso quatro perguntas com qualquer fundador antes de recomendar contratar uma software house, e antes de aceitar trabalhar com um cliente novo. Se três das quatro respostas vão na mesma direção, a decisão é fácil. Quando elas se dividem, vale conversar mais antes de assinar qualquer coisa.

1. O quão claro está o spec?

Não é “você tem um documento de requisitos.” É “você sabe explicar, em duas frases, qual problema você resolve e para quem”. Software house é boa em traduzir uma ideia clara em sistema. Não é boa (nem barata) em ajudar você a descobrir qual é a ideia.

Se a resposta é “ainda estou validando o problema,” pare. Faça discovery primeiro, com você mesmo e os primeiros clientes. Compre uma assinatura do Bubble se precisar. Volte para a software house quando o spec estiver firme. Cada hora de software house gasta em descoberta de produto custa cinco vezes o que custaria gasta em código.

2. O quão central o sistema é para o negócio?

Há sistemas que são o produto (a fintech inteira roda em cima do core bancário) e sistemas que destravam operação (o painel interno que liberou três pessoas do time de operações). Os dois merecem software bem feito. Mas o tipo de relação contratual e o tipo de transição que você quer no final são diferentes.

Para sistemas centrais, planeje desde o dia um a internalização do time. A software house ideal aqui é a que ajuda você a contratar seus primeiros engenheiros, transfere o conhecimento, e some quando você não precisa mais dela. Para sistemas internos, software house pode ser o time permanente. Não tem nada de errado em manter um parceiro de longo prazo cuidando das ferramentas internas; só precisa estar combinado.

3. Qual seu estágio e runway?

Pré-seed e seed com runway curto: a velocidade é tudo. Software house entrega rápido porque o time já está montado. Usar três meses para contratar um CTO antes de começar a construir é três meses que você não vai recuperar.

Series A em diante, com PMF claro e roadmap longo, a economia muda. Time interno fica mais barato no acumulado, gera ativo (talento que cresce com a empresa) e cria continuidade. Esse é o ponto natural de transição: software house para tirar a empresa do chão, time interno para escalar.

4. Quem vai dono do código em dezoito meses?

Essa é a pergunta que separa as software houses sérias das que não são. Pergunte explicitamente, antes de assinar: o repositório vai estar no GitHub da minha empresa desde o dia um. A documentação vai ser minha. Quando contratar meus primeiros engenheiros, sua equipe vai sentar com eles, transferir contexto, e sair sem gerar trauma.

Se a software house tergiversa ou condiciona a saída a algum tipo de licença, royalty ou suporte obrigatório, corre. Os contratos honestos são curtos sobre esse ponto. O código é seu. Sempre foi.

Como avaliar uma software house sem fingir conhecimento técnico

Esse é o ponto onde mais fundadores não-técnicos travam. Você não precisa avaliar a stack que eles propõem. Precisa avaliar como eles pensam.

Peça o post-mortem do projeto que deu mais errado. Software house séria tem um. Software house que diz “nunca tivemos problema” está mentindo ou está há pouco tempo no mercado. O que importa não é o erro; é o nível de detalhe e de auto-crítica na resposta.

Peça referências e ligue para elas com câmera fechada. Ex-clientes que terminaram o projeto há mais de seis meses são a melhor amostra. Pergunte coisas concretas: o orçamento foi respeitado? Quem mexia no sistema depois que vocês saíram? Vocês contratariam de novo? Quando uma referência hesita, você está ouvindo a verdade.

Peça para conhecer quem vai trabalhar no seu projeto, não só o sales. Software house séria deixa você conversar com o tech lead que vai puxar o time. Software house ruim mantém um atendimento comercial muito bom e esconde a equipe que entrega.

Peça uma proposta com escopo, não com horas. “Vamos cobrar 1.200 horas a R$ 250” não é uma proposta. Isso é um cheque em branco. “Vamos entregar o módulo X por R$ Y, em Z semanas, com critérios de aceite escritos” é uma proposta. Software house que só vende horas está dizendo que não tem confiança no próprio escopo.

Olhe para o portfólio com ceticismo. Lindo no Behance não é sinônimo de bom em produção. Pergunte qual desses projetos ainda está rodando, qual foi descontinuado, qual o cliente comprou e levou para outro fornecedor. A história depois do lançamento é o que conta.

Quanto custa contratar uma software house no Brasil

Existe uma faixa razoável e existem extremos perigosos. As médias abaixo são para projetos de produto digital de complexidade moderada, com time pequeno (2 a 5 pessoas alocadas), em São Paulo, Rio ou outras capitais com mercado tech maduro.

Hora-homem média no mercado BR (2026): R$ 180 a R$ 350 a hora para times sênior, R$ 100 a R$ 180 para times mistos com mais juniores. Abaixo de R$ 100, desconfie. Acima de R$ 400, você está pagando uma marca, e isso pode valer ou não.

Projeto de MVP (3 a 4 meses): R$ 250 mil a R$ 600 mil é a faixa em que projetos honestos costumam acontecer. Abaixo disso, ou o escopo é minúsculo, ou alguém vai cortar canto. Acima, ou a complexidade é real (regulação, integrações pesadas, ML aplicado), ou você está pagando overhead.

Squad alocado mensal (2 a 3 pessoas, contínuo): R$ 80 mil a R$ 180 mil por mês, dependendo de senioridade.

Compare com o time interno equivalente: um CTO pleno e dois engenheiros sênior em São Paulo, com encargos, ferramentas e equipamentos, custam algo entre R$ 90 mil e R$ 130 mil por mês, e levam três a seis meses até estarem entregando no ritmo. Software house custa mais por hora, mas começa a entregar na semana três.

Não tome essa decisão em planilha. Tome em runway. Quanto tempo até você precisar de um produto rodando, e quanto da sua banda você quer queimar gerindo gente nesse intervalo?

A conversa do contrato

Antes de assinar, exija explicitamente:

• Propriedade do código. O repositório é da sua empresa, no GitHub ou GitLab da sua empresa, desde o primeiro commit. Sem licenças, sem cláusulas que limitem uso futuro, sem dependência de plataforma proprietária do fornecedor.
• Cláusula de saída sem trauma. Como termina, se um dos lados decidir que não dá mais? Aviso prévio, transição assistida, transferência de conhecimento documentada. Tudo escrito.
• SLA de comunicação, não só de uptime. Em quanto tempo eles respondem? Quem é seu ponto de contato? O que acontece quando o tech lead sai de férias?
• Critérios de aceite por entrega. O que conta como “feito” para cada módulo. Concreto, mensurável.
• Cap em scope creep. Mudanças de escopo geram um adendo, com prazo e custo recalculados. Não geram bola de neve.

Esse é o ponto onde mais relações azedam, e azedam por motivo bobo: ninguém escreveu como seria a saída. Assine com saída clara.

Sinais de alerta no meio do projeto

Algumas relações com software house começam bem e azedam. Os sinais aparecem antes da entrega final.

A demo semanal vira mensal. Software house séria mostra trabalho toda semana. Quando o ritmo de demos cai, é porque o ritmo de entrega caiu, ou porque tem coisa que a equipe não quer mostrar.

O tech lead muda sem aviso. Pessoas saem, é normal. O que não é normal é descobrir três sprints depois que quem está liderando o seu projeto não é mais quem você entrevistou. Software house sólida comunica troca de pessoas-chave imediatamente.

Pedidos de mudança de escopo viram tabu. Você muda algo, eles aceitam sem renegociar prazo. Cinco mudanças depois, a entrega atrasa três meses e ninguém sabe por quê. Mudança de escopo deveria gerar fricção saudável; quando não gera, alguém está acumulando dívida invisível.

Os commits ficam genéricos. “fix bug”, “adjustments”, “WIP” como mensagem de commit do dia inteiro. É o equivalente em código do “vou te explicar depois”.

Quando dois desses sinais aparecem juntos, peça uma conversa franca, com agenda escrita, sem o sales na sala. A maioria das relações azedas pode ser corrigida se a conversa acontecer no mês três. Quase nenhuma pode ser corrigida no mês oito.

A escolha não é entre fornecedores; é entre futuros

Toda contratação de software house é, na real, uma aposta sobre que tipo de empresa você quer ser daqui a dezoito meses. Software house barata e descomprometida te entrega um sistema que funciona até a próxima rodada e depois trava. Software house séria te entrega um sistema, um manual e uma transição limpa para o time que você ainda vai contratar.

A diferença em preço entre as duas é menor do que parece. A diferença em destino é o resto da empresa.

Se está difícil decidir entre opções, volte às quatro perguntas. O quão claro está o spec, o quão central é o sistema, qual seu estágio e quem é dono do código em dezoito meses. Em geral, três das quatro respostas apontam para o mesmo lugar. Quando apontam, vá. Quando não apontam, espere mais uma semana e converse com mais um cliente da software house antes de assinar.

A decisão certa não é a mais barata, nem a mais sofisticada. É a que deixa você dormindo sabendo quem está construindo o que e por quê.