O que você está pagando quando contrata uma software house

Este post é escrito de fora, não de dentro. Eu não tenho software house: sou engenheiro solo e a HaruoDev sou eu. O que eu tenho é o outro lado da mesa: passei a carreira trabalhando dentro desse tipo de empresa, como desenvolvedor, na ThoughtWorks, na Clade & Co., na ilegra e na Password Informática. Vi o que entra na conta antes de ela virar um PDF de proposta.

É essa a utilidade aqui: se você vai contratar, ajuda entender o que está sendo cobrado e por quê. Nada abaixo é conselho sobre me contratar: eu não vendo o serviço de que este texto fala.

---

1. O preço não é o custo do programador

A confusão mais cara que um empresário faz é comparar a hora de uma software house com o salário de um desenvolvedor. São coisas diferentes, e a diferença não é ganância, é o que a hora carrega junto.

Quando você paga uma hora de projeto, está pagando por uma lista que quase nunca aparece discriminada no orçamento:

• Gente que não escreve código no seu projeto. Alguém entende o problema antes de virar tarefa; alguém decide a arquitetura; alguém testa; alguém cuida do deploy e do que acontece às três da manhã. Essas funções existem tendo ou não um nome de cargo próprio. Numa empresa grande são cinco pessoas; numa pequena, duas pessoas usando cinco chapéus. Você paga pelos cinco chapéus de um jeito ou de outro.
• Tempo ocioso entre contratos. Nenhuma empresa de serviço tem 100% do time alocado o ano inteiro. O intervalo entre um projeto e o próximo está embutido na hora dos projetos que existem.
• Garantia. O bug que aparece depois da entrega vai ser corrigido por alguém que não está sendo pago de novo por aquilo.
• Rotatividade. Quando o desenvolvedor que conhecia o seu sistema sai, o substituto leva semanas para chegar ao mesmo lugar. Esse risco é da empresa, e ele tem preço.

Nada disso justifica qualquer preço. Justifica que o preço não seja o salário dividido por 160, e explica por que o orçamento muito abaixo dos outros normalmente não é eficiência: é uma dessas linhas que alguém decidiu não cobrar, e você descobre qual no meio do projeto.

2. O que uma software house deve fazer (e muitas não fazem)

Três coisas parecem básicas e são raras:

1. Entender o negócio antes de escrever a primeira linha. Não adianta o software perfeito para o problema errado. Isso exige conversa, pesquisa e, muitas vezes, dizer “não” ao que o cliente pediu, porque o que ele precisa é outra coisa.

2. Entregar em ciclos curtos, não tudo no final. Nada de sumir por seis meses e voltar com um “pronto”. Entrega funcional a cada duas ou três semanas: você vê, testa, ajusta.

3. Responder pelo resultado, não só pelo código. Se o software não está gerando o resultado esperado, a resposta certa é sentar para entender por quê, não “mas o código funciona”.

O ciclo que sustenta isso é sempre o mesmo, com nomes diferentes: entender o problema, decidir a arquitetura, entregar em fatias, sustentar o que foi entregue. Vale a pena perguntar, na primeira conversa, quem faz cada uma dessas quatro coisas e quanto tempo cada uma leva. A resposta diz mais sobre a empresa do que o portfólio.

3. Bandeiras vermelhas na primeira conversa

🚩 “Isso é simples, fazemos em uma semana.” Ninguém que entende de software diz isso antes de entender o problema.

🚩 “Damos um orçamento fechado sem conhecer o projeto.” Orçamento fechado sem escopo detalhado é loteria. Ou você paga caro demais, ou recebe um produto genérico, ou as duas coisas em sequência.

🚩 “Usamos a tecnologia mais moderna.” A melhor tecnologia é a que resolve seu problema com o menor custo e risco. Adequado vence moderno.

🚩 A primeira preocupação é burocracia. NDA é legítimo. Mas se a primeira reunião é sobre contrato em vez de sobre o seu negócio, você já sabe o que vai ser priorizado depois.

🚩 Ninguém pede para falar com seus usuários finais. Quem não se interessa por quem vai usar o sistema está interessado em entregar código, não em resolver o problema.

4. Como ler um orçamento sem ser técnico

Você não precisa saber programar para avaliar uma proposta. Precisa procurar quatro coisas:

O escopo está escrito com critério de aceite. “Módulo de relatórios” não é escopo. “Relatório X, com os campos A, B e C, exportável em CSV” é. Sem critério de aceite não existe “pronto”, e sem “pronto” não existe prazo.

As premissas estão explícitas. Todo orçamento assume coisas: que a API do terceiro funciona, que os dados existem, que alguém do seu lado responde em 48 horas. Quando as premissas estão escritas, quebrar uma delas vira uma conversa. Quando não estão, vira uma cobrança extra.

Está dito o que acontece quando o escopo muda. Vai mudar. A pergunta útil não é “vai mudar?”, é “como a gente combina o preço quando mudar?”.

O código é seu, por escrito. Parece absurdo precisar dizer, mas há empresa que usa o código como refém. Deixe no contrato: o código-fonte é seu, o repositório é seu, o acesso à infraestrutura é seu.

5. Como saber, durante o projeto, se está indo bem

Toda entrega é testável. Você consegue usar o que foi entregue e mostrar para a sua equipe? Se não, “entregue” está querendo dizer outra coisa.

O custo é previsível. Imprevisto acontece. Ele deve chegar com antecedência e com opções, não como fato consumado na fatura.

Você entende o que está sendo construído. Se você sai das reuniões sem entender o que foi dito, o alinhamento não está funcionando, e alinhamento quebrado é o que produz o software certo para o problema errado.

6. O seu lado da conta

O ponto mais difícil de admitir: o cliente também decide o resultado. Uma software house não é uma máquina onde você empurra requisitos por baixo da porta e retira o produto do outro lado.

• Uma pessoa decide. Três sócios com opiniões diferentes respondendo em dias alternados é a forma mais barata de dobrar o prazo.
• Resposta rápida. Cada dia parado esperando aprovação é um dia pago.
• Feedback honesto sobre as entregas. “Está bonito” não ajuda. “Essa tela não resolve o problema do meu cliente porque X” ajuda muito.
• Software vive. O que entra no mês 1 não é o que roda no mês 12, e isso é bom, não é falha de planejamento.

7. Quando uma software house é a resposta errada

Vale dizer, já que este texto não está vendendo o serviço:

• Se o problema já tem produto pronto, comprar assinatura quase sempre ganha de mandar construir. Software sob medida é caro para sempre, não só na entrega.
• Se o escopo é pequeno e claro, um profissional autônomo costuma sair mais barato e mais rápido, a estrutura que a software house cobra existe para projetos que precisam dela.
• Se você ainda não sabe o que quer, contrate primeiro a descoberta, e só ela. É o contrato mais barato que existe e o que mais evita prejuízo.

A pergunta certa nunca foi “qual software house é a melhor?”. É “o meu problema precisa mesmo de uma?”.

---

Douglas Haruo, engenheiro de software há 15 anos, cinco deles em risco e fraude numa fintech de pagamentos. haruo.dev