Comprar software tem uma assimetria que quase nenhuma outra compra tem: você paga antes de conseguir avaliar o que recebeu, e continua sem conseguir avaliar depois.
Comprar uma máquina é diferente — ela produz ou não produz. Software funciona na demonstração e revela o problema seis meses depois, quando trocar de fornecedor custa mais que aguentar.
Não dá para eliminar essa assimetria. Dá para reduzi-la bastante, com perguntas feitas antes de assinar.
1. "O que exatamente eu recebo, além do sistema no ar?"
A resposta que interessa é uma lista de artefatos, não uma promessa de qualidade.
Especificação de cada funcionalidade, aprovada por você antes da construção. Registro das decisões de arquitetura, com o motivo de cada uma. Suíte de testes automatizados e o resultado da execução. Instruções de como subir o sistema do zero.
Se a lista for curta, o que você está comprando é dependência: o sistema pode até funcionar, mas evoluí-lo exigirá sempre a mesma empresa, porque só ela sabe como aquilo é por dentro. É assim que se vira refém — não por má-fé, por ausência de artefato.
2. "O código e os artefatos ficam comigo?"
Precisa ser sim, por escrito, no contrato. E precisa incluir tudo: código, especificações, testes, decisões, scripts de infraestrutura.
Um sinal de alerta específico: sistema construído sobre plataforma proprietária do fornecedor. Mesmo com o "código" seu, você não consegue rodá-lo em lugar nenhum sem a licença dele. A pergunta que desfaz a ambiguidade é direta: "se eu levar isso para outra empresa amanhã, o que falta para ela conseguir rodar?"
3. "Como é medido o preço?"
Existem dois modelos honestos, e a diferença importa.
Escopo fechado: preço e entregas definidos antes. O risco de estimativa fica com o fornecedor. Exige um escopo bem definido — e é justamente por isso que uma etapa paga de diagnóstico antes costuma valer a pena.
Por tempo e material: você paga pelas horas. Faz sentido quando o escopo genuinamente não dá para fechar — pesquisa, evolução contínua de produto. O risco de estimativa fica com você.
O que não é honesto é escopo fechado que vira tempo e material na prática, via aditivo a cada mês. Se o fornecedor propõe escopo fechado, pergunte o que acontece quando algo é descoberto no meio: quem paga? A resposta revela qual modelo é de verdade.
4. "Como eu confiro a qualidade, sem ser técnico?"
Aqui a resposta ruim é a mais comum: "você vai ver funcionando na homologação".
Ver funcionando prova que o caminho feliz funciona no dia da demonstração. Não diz nada sobre o que acontece com dez vezes mais volume, sobre o caso de erro que ninguém testou, sobre o dado de um cliente aparecer para outro.
A resposta boa aponta para algo mecânico: relatório de execução de testes automatizados, verificação de padrão que roda a cada mudança, teste rodando contra banco de dados real. Você não precisa entender o conteúdo — precisa poder pedir e receber, e poder mostrar a um técnico de sua confiança.
5. "Quem mantém depois, e quanto custa?"
Software não acaba na entrega. Custo de manutenção existe sempre, e ignorá-lo na hora da compra é o erro mais caro da lista.
Pergunte: quanto custa uma correção? E uma funcionalidade pequena? Qual o prazo de resposta quando o sistema cai? E, principalmente: o que preciso ter para conseguir contratar outra empresa para manter isso?
Fornecedor que responde bem a esta última é justamente aquele de quem você vai ter menos vontade de sair.
6. "O que você me diria para eu não contratar?"
É a pergunta mais reveladora, e a que quase ninguém faz.
Todo problema tem uma solução que não passa por construir software: mudar o processo, comprar pronto, usar planilha por mais um ano. Fornecedor que nunca menciona nenhuma dessas está respondendo à pergunta "como faço para vender", não "o que resolve o seu problema".
Quem diz "nesse caso, comprar pronto sai melhor" está deixando dinheiro na mesa naquele momento. E é exatamente por isso que dá para acreditar quando ele diz que sob medida vale a pena.
O resumo
A assimetria não vai desaparecer, mas ela diminui quando o que você compra tem forma conferível. Software é a parte que você não consegue avaliar. Os artefatos — especificação, decisão registrada, teste executado — são a parte que você consegue.
Contrate quem entrega os dois.
Como trabalhamos: escopo fechado como modo padrão, artefatos de verificação em cada entrega, e código e documentação sempre no seu repositório. Detalhe em como trabalhamos.