Os erros mais caros de quem contrata o primeiro sistema

Quem contrata software pela primeira vez erra nos mesmos dez pontos, com uma regularidade que permite prever o desfecho. A boa notícia é que todos são decididos antes da primeira linha de código, o que significa que todos podem ser evitados por quem sabe onde olhar. Cada erro abaixo vem com o que ele custa na prática.

1. Pedir preço antes de escrever o escopo

O que acontece: você recebe três orçamentos com valores muito diferentes e não consegue compará-los, porque cada fornecedor imaginou um projeto.

O que custa: além da escolha ruim, você paga a margem de incerteza que cada fornecedor embutiu. Sem escopo, essa margem costuma valer de 20% a 40% do orçamento.

Como evitar: escreva três a cinco páginas descrevendo problema, usuários, fluxos, regras e o que fica fora. Mande o mesmo documento para todos.

2. Escolher pelo menor preço entre propostas incomparáveis

O que acontece: a proposta mais barata era a que menos entendeu o problema. O que faltava reaparece como aditivo.

O que custa: o valor final costuma ultrapassar o da proposta que parecia cara, com o agravante do atraso.

Como evitar: compare linha a linha o que cada proposta inclui de integrações, migração, permissões e garantia. Preço só é comparável entre escopos iguais.

3. Não garantir código, dados e credenciais em nome da empresa

O que acontece: meses depois, você descobre que o servidor está na conta pessoal do desenvolvedor e o repositório também.

O que custa: este é o erro mais caro da lista. Ele não custa meses, custa a possibilidade de trocar de fornecedor sem recomeçar do zero.

Como evitar: repositório, servidor, banco, domínio e chaves de API em contas corporativas suas, com o fornecedor convidado. Cláusula de cessão de direitos patrimoniais no contrato.

4. Tentar lançar tudo de uma vez

O que acontece: o projeto de três meses vira de nove, e nada entra em uso enquanto isso.

O que custa: meses sem retorno e o risco de construir funcionalidades que ninguém usa. É comum que boa parte da lista original nunca seja aberta depois de pronta.

Como evitar: identifique o menor conjunto que já resolve a dor principal, coloque em uso real e decida o resto com dados de uso.

5. Não envolver quem executa o processo

O que acontece: o sistema é especificado com a gerência e entregue para a operação, que não trabalha daquele jeito.

O que custa: retrabalho no fim do projeto, quando mudar é mais caro, e rejeição no uso, o pior desfecho possível.

Como evitar: entreviste quem executa antes de escrever o briefing. As exceções que quebram projetos moram no conhecimento dessas pessoas.

6. Aceitar prazo sem marcos intermediários

O que acontece: o projeto tem uma única data no fim e você só descobre o atraso perto dela.

O que custa: perda total de capacidade de reagir. Quando o atraso aparece, não há mais tempo para corrigir rota.

Como evitar: exija entregas verificáveis a cada duas ou três semanas, com pagamento atrelado à homologação.

7. Não definir um responsável do lado do cliente

O que acontece: cinco pessoas pedem coisas diferentes diretamente ao desenvolvedor, e ninguém tem o quadro completo.

O que custa: escopo aberto, prioridades conflitantes e semanas paradas esperando decisão.

Como evitar: nomeie uma pessoa com autoridade sobre orçamento e agenda reservada para o projeto.

8. Ignorar o custo de operação

O que acontece: o sistema fica pronto e aparece uma conta mensal que ninguém previu, servidor, banco, e-mail transacional, monitoramento.

O que custa: orçamento estourado no primeiro ano e, pior, a tentação de cortar backup e monitoramento para economizar.

Como evitar: peça o custo anual estimado de infraestrutura antes de assinar e reserve de 15% a 20% do valor do projeto por ano para manutenção evolutiva.

9. Não testar de verdade antes de aprovar

O que acontece: a homologação vira uma reunião de demonstração em que o fornecedor mostra o caminho feliz.

O que custa: defeitos descobertos em produção, com dados reais e usuários reais, quando a correção custa mais e a confiança já foi afetada.

Como evitar: reserve dias úteis para que pessoas da operação usem o sistema com dados reais, tentando quebrar. Registre os problemas por escrito antes de liberar a parcela.

10. Não combinar o que acontece depois da entrega

O que acontece: o sistema entra no ar, aparece um defeito na segunda semana e começa a discussão sobre se aquilo está na garantia.

O que custa: atrito exatamente quando você mais precisa de suporte, e o risco de ficar sem manutenção logo no período mais instável.

Como evitar: defina em contrato o prazo de garantia, o que ela cobre, o tempo de resposta e as condições de manutenção mensal depois dela.

Resumo em tabela

Erro	Custo típico	Decisão que evita
Pedir preço sem escopo	Margem de incerteza no orçamento	Briefing escrito antes
Escolher pelo menor preço	Aditivos e atraso	Comparar escopos, não valores
Não garantir propriedade	Recomeçar do zero	Cláusula e contas corporativas
Lançar tudo de uma vez	Meses sem retorno	Primeira versão enxuta
Não ouvir a operação	Retrabalho e rejeição	Entrevistas antes do briefing
Prazo sem marcos	Descobrir o atraso tarde	Entregas a cada 2-3 semanas
Sem responsável no cliente	Escopo aberto	Um decisor nomeado
Ignorar operação	Orçamento estourado	Custo anual estimado
Homologar por demonstração	Defeitos em produção	Teste com dados reais
Sem regra pós-entrega	Atrito e sistema sem suporte	Garantia e manutenção em contrato

Nenhum desses erros é técnico. Todos são decisões de gestão tomadas antes do início, o que significa que a maior parte do risco de um projeto de software se resolve num documento e num contrato, não num editor de código.