Como contratar uma software house sem cair em cilada: o checklist antes de assinar

Você pediu orçamento para três empresas. Uma respondeu em duas horas com um valor fechado. Outra mandou uma proposta de 40 páginas cheia de siglas. A terceira quer "marcar uma call para entender melhor". Os valores variam de R$ 30 mil a R$ 180 mil para o que, na sua cabeça, é o mesmo projeto. E agora? Se você está pesquisando como contratar uma software house sem cair em cilada, provavelmente já sentiu esse frio na barriga: assinar um contrato de seis dígitos com uma empresa que você conheceu semana passada, para construir algo que você não sabe avaliar tecnicamente.

Quem já passou por um projeto travado sabe do que estou falando. A boa notícia: os desastres de desenvolvimento sob medida seguem padrões previsíveis. Dá para detectar quase todos antes de assinar, com as perguntas certas.

Por que tanto projeto de software dá errado

Não é porque as empresas são desonestas. A maioria dos projetos travados que eu herdei ao longo dos anos nasceu de três causas estruturais:

• Escopo combinado no aperto de mão. Cliente e fornecedor imaginaram produtos diferentes e só descobriram isso no meio do desenvolvimento, quando mudar custa caro.
• Quem vendeu não é quem codifica. Um comercial experiente fechou o contrato, e o código foi parar na mão de um júnior ou de um terceirizado que o cliente nunca conheceu.
• Ninguém falou de manutenção. O contrato cobria a entrega, não a vida do sistema depois dela. Seis meses após o lançamento, o primeiro bug crítico vira uma negociação do zero.

Nenhuma dessas causas aparece na proposta comercial. Todas aparecem quando você faz as perguntas certas na reunião de vendas.

Como contratar uma software house: as 7 perguntas antes de assinar

Antes de assinar qualquer contrato, pergunta isso:

1. Quem exatamente vai escrever o código? Nome, senioridade, se é funcionário ou terceirizado. Peça para conversar com essa pessoa antes de fechar. Se a empresa enrolar para apresentar o time técnico, é porque o time técnico não impressiona.
2. O código é meu desde o primeiro commit? A resposta certa é sim, com repositório no seu nome (GitHub ou similar) e acesso desde o início. Propriedade do código "após quitação" é aceitável; código que fica com o fornecedor "por segurança" não é.
3. O que acontece se eu quiser trocar de fornecedor no meio? Uma empresa séria responde com naturalidade: você leva o repositório, a documentação e os acessos. Se a resposta envolver constrangimento ou multa desproporcional, você está comprando dependência, não software.
4. Como funciona a manutenção depois da entrega? Peça valores agora, não depois. Uma referência de mercado: manutenção mensal costuma ficar entre 5% e 15% do valor do projeto por ano, dependendo da criticidade. Quem não tem resposta para isso não pensou no seu sistema além da entrega.
5. Quais entregas eu vejo, e quando? A resposta boa tem entregas funcionais a cada duas ou quatro semanas, com você testando em ambiente real. "Você vê tudo pronto no final" é a receita clássica do projeto travado.
6. O que vocês recomendam CORTAR do meu escopo? Essa é a minha favorita. Uma empresa que só concorda com tudo que você pediu está vendendo horas. Uma que sugere tirar funcionalidade da primeira versão está pensando no seu resultado.
7. Posso falar com dois clientes anteriores? Não peça o portfólio, peça o telefone. Cinco minutos com um ex-cliente valem mais que qualquer case bonito no site.

Red flags: quando o barato sai caro

O barato que sai caro aqui é o seguinte: os sinais de problema quase sempre aparecem antes da assinatura, disfarçados de vantagem.

• Orçamento fechado sem levantamento de escopo. Se a empresa te deu um preço sem pelo menos uma reunião de descoberta, ela chutou. E o chute será corrigido depois, com aditivos, ou com qualidade cortada onde você não vê.
• Prazo impossível como argumento de venda. "Entregamos em 30 dias o que os outros fazem em 4 meses" não é eficiência, é escopo que vai ser cortado sem te avisar. Um app funcional com backend, por menor que seja, raramente sai em menos de 8 a 12 semanas.
• Desconto agressivo para fechar hoje. Software sob medida não é liquidação de estoque. Pressão de urgência na venda costuma indicar caixa apertado, e caixa apertado vira projeto abandonado.
• Tecnologia como resposta para tudo. Se a proposta fala mais de stack do que do seu problema de negócio, o fornecedor vai construir o que ele sabe fazer, não o que você precisa.
• Contrato sem critério de aceite. "Entrega do sistema" não é critério. "Fluxo de cadastro, pagamento e emissão de nota funcionando em produção" é. Sem critérios objetivos, qualquer disputa vira palavra contra palavra.

Como comparar propostas que parecem incomparáveis

Não existe resposta única, mas existe conta certa. Três propostas com valores muito diferentes quase nunca descrevem o mesmo projeto. Antes de comparar preço, normalize o que está sendo comparado:

• Escopo: liste as funcionalidades de cada proposta lado a lado. A de R$ 30 mil provavelmente não inclui coisas que a de R$ 180 mil inclui (painel administrativo, integração de pagamento, testes, deploy). Some o que falta e o barato encolhe.
• Quem executa: um sênior a R$ 150/hora entrega em 100 horas o que um júnior a R$ 60/hora entrega em 300, com retrabalho. Preço por hora isolado não diz nada.
• Custo total de 2 anos: some desenvolvimento + manutenção mensal + hospedagem + evolução prevista. É esse número que vai para a sua planilha, não o valor da proposta.
• Custo de saída: o que acontece se der errado? Propriedade do código, documentação e repositório no seu nome reduzem o prejuízo de uma troca. Isso tem valor, mesmo que não apareça no preço.

E uma verificação honesta antes de qualquer proposta: você precisa mesmo de software sob medida? Se um SaaS de prateleira resolve 80% do seu problema por R$ 300/mês, comece por ele. Sob medida faz sentido quando o processo é o seu diferencial competitivo, quando a integração entre sistemas virou gargalo, ou quando a operação já não cabe em ferramenta genérica. Uma software house séria te diz isso na primeira reunião, mesmo perdendo a venda.

O que uma software house séria faz diferente

Aqui vale abrir o jogo sobre como a gente trabalha na OCA. Nós somos um time sênior em São Paulo, e a nossa régua interna é simples: só recomendamos o que a gente mesmo opera em produção. Nosso próprio produto, o Revo App, roda com mais de 40 mil usuários e um checkout que converte a 90%. Quando falamos de manutenção, prazo ou arquitetura, é porque acordamos todo dia com um sistema nosso no ar.

Na prática, isso significa que passamos no nosso próprio checklist: quem vende é quem codifica, o repositório nasce no nome do cliente, as entregas são quinzenais e testáveis, e a primeira coisa que fazemos em uma reunião de descoberta é sugerir o que cortar do escopo. Já dissemos "você não precisa disso agora" para mais clientes do que consigo contar, e é exatamente por isso que os que fecham, ficam. Você pode ver os projetos que construímos e operamos para calibrar sua régua de comparação.

Próximo passo: monte seu briefing antes de pedir orçamento

Ação gratuita que melhora qualquer negociação: escreva uma página com (1) o problema de negócio que o sistema resolve, (2) as 5 funcionalidades essenciais da primeira versão, (3) o que fica de fora por enquanto, e (4) quem vai usar o sistema no dia a dia. Mande esse documento para todos os fornecedores. Propostas sobre o mesmo briefing finalmente ficam comparáveis, e a qualidade das respostas já filtra metade das ciladas.

E se quiser testar o checklist deste artigo em uma conversa real, sem compromisso:

Converse com a OCA sobre o seu sistema

Faça as 7 perguntas. A gente responde todas.