Contratei uma software house e não deu certo — os 3 erros mais comuns

---

Já estive dos dois lados da mesa.

Como desenvolvedor, trabalhei em software houses que entregavam produtos digitais para empresas como Chipper Cash (fintech backed by Jeff Bezos) e ThoughtWorks (uma das consultorias de tecnologia mais respeitadas do mundo). Vi de perto o que faz um projeto dar certo.

Como founder, também já contratei terceiros e vi projetos queimarem orçamento, prazo e paciência.

Os erros se repetem. E são evitáveis.

Erro #1: Escopo que é um romance, não um documento técnico

O cenário clássico: você senta com a software house, explica sua ideia, eles dizem “entendemos”, e duas semanas depois entregam algo completamente diferente do que você imaginou.

O problema não é a software house — é que “entendemos” não substitui um documento de escopo.

O que funciona de verdade

Um bom escopo técnico tem:

• O que o sistema faz — funcionalidades listadas uma a uma, em linguagem que qualquer pessoa entende
• O que o sistema NÃO faz — igualmente importante. Evita o “mas eu achei que vinha incluído”
• Regras de negócio explícitas — “se o cliente tiver mais de 3 parcelas em atraso, o sistema bloqueia novo pedido”. Isso não é detalhe de implementação, é regra de negócio.
• Critérios de aceite — como saber se a funcionalidade está pronta. Ex: “O usuário faz login, vê o dashboard com os indicadores X, Y, Z atualizados em tempo real”
• O que não está no escopo — tão importante quanto o que está

Na prática: Peça pra software house escrever o escopo e te mandar pra revisão antes de começar. Se eles não conseguem escrever um escopo claro, o projeto também não vai ser claro.

Erro #2: Ninguém olha o código (e depois é tarde demais)

Muita gente contrata software house achando que “code review” é coisa de open source ou de empresa grande. Não é.

Toda empresa que entrega software deveria ter cada linha de código revisada por outro desenvolvedor antes de ir pra produção. Isso não é frescura — é o padrão da indústria.

O que acontece sem code review

• Bugs óbvios vão pra produção
• Código incompreensível que ninguém consegue dar manutenção depois
• “Dívida técnica” que na prática significa: contratar a mesma software house pra sempre porque ninguém mais entende o sistema
• Segurança: credenciais vazadas, APIs expostas, dados de cliente vulneráveis

Perguntas pra fazer antes de contratar

• “Como funciona o processo de revisão de código de vocês?”
• “Cada linha é revisada por outro dev antes de subir?”
• “Posso ver exemplos de PRs (pull requests) de projetos anteriores?”
• “Quem tem acesso de produção e como vocês controlam isso?”

Se a resposta for “não temos um processo formal de revisão” ou “confiamos nos nossos devs”, desconfie. Confiança não substitui processo.

Erro #3: Comunicação que vira fóssil

O terceiro erro é o mais comum e o mais silencioso.

Começa assim: vocês trocam ideia no WhatsApp, resolvem uma dúvida rapidamente. Depois de duas semanas, ninguém lembra o que foi decidido. O desenvolvedor que participou da conversa sai da empresa. O novo olha pro código e não faz ideia do que implementar.

O que funciona

• Tudo documentado em issues. Cada decisão, cada requisito, cada mudança de escopo vira uma issue. Não é burocracia — é memória do projeto.
• Comunicação assíncrona primeiro. Se não é urgente, não é WhatsApp. É issue, é e-mail, é documento. Aí quando precisar de uma call, ela é objetiva.
• Pull requests com descrição. Cada entrega de código vem acompanhada de: “O que foi feito, por que foi feito assim, como testar, prints se aplicável.”
• Reunião semanal de sincronia. 30 minutos, semanal, com pauta definida. Nada de reunião de 2h onde ninguém lembra o que decidiu.

O sinal de alerta

Se nas primeiras semanas a software house evita documentar decisões por escrito, isso é um padrão, não um acidente. Empresas maduras documentam naturalmente, sem precisar de cobrança.

Como evitar os 3 erros

Erro	Prevenção
Escopo vago	Exija escopo escrito com critérios de aceite
Sem code review	Pergunte sobre o processo de revisão ANTES de contratar
Comunicação fóssil	Exija tudo documentado em issues, não só em chat

Um bom parceiro de tecnologia não entrega só código — entrega clareza, previsibilidade e documentação. O código é consequência.

Se a software house com quem você está falando entrega os 3, o projeto tem tudo pra dar certo. Se falta qualquer um deles, é melhor continuar procurando.

---

Sobre a Haruo: Haruo é uma software house full-stack especializada em produtos web, APIs e automação com IA. haruo.dev

---

Buscando uma software house confiável? Fale com a Haruo →