O preço do fornecedor errado aparece depois que o projeto parece entregue

Tem projeto que é entregue no prazo, apresentado com cara de missão cumprida e tratado como se o problema estivesse resolvido.

A interface está pronta. O sistema entrou no ar. Existe algo funcionando. O fornecedor cumpriu a etapa combinada.

E, por um momento, a sensação é de alívio.

Só que, em muitos casos, é aí que a conta real começa.

Porque o preço do fornecedor errado raramente aparece de forma clara no contrato. Ele aparece depois: na convivência com o projeto, na rotina de manutenção, na dificuldade de evoluir, na dependência criada e na operação tentando sustentar uma entrega que parece concluída, mas ainda está longe de ser madura.

O fornecedor errado parece aceitável no começo

Esse é um dos motivos pelos quais esse erro é tão comum.

No início, tudo parece razoável.

• a proposta convence
• o prazo parece bom
• a apresentação passa segurança
• o preço parece viável
• existe uma sensação de escolha pragmática

E, quando a primeira entrega acontece, a empresa ganha um argumento forte para acreditar que tomou uma boa decisão.

Só que projeto entregue não é a mesma coisa que estrutura saudável.

A conta começa a aparecer depois do entusiasmo inicial

É quando o produto encontra a operação real que o preço da escolha começa a aparecer.

A empresa quer ajustar alguma coisa simples e percebe que aquilo demora mais do que deveria.

Precisa evoluir uma funcionalidade e descobre que a base está mais rígida do que parecia.

Tenta integrar melhor um sistema e encontra fricção demais.

Precisa de manutenção e sente dependência excessiva de quem construiu.

O time interno começa a trabalhar em volta do produto em vez de trabalhar com o produto.

E o que parecia entrega concluída vai se revelando como solução cara de sustentar.

Esse raciocínio conversa com o fornecedor de tecnologia errado encarece a operação inteira. Em muitos casos, o erro não está só no fornecedor. Está na forma como a empresa enxerga a entrega inicial como sinal de decisão certa.

O custo que não estava na proposta

Esse é o ponto mais importante nessa conversa.

O problema quase nunca está só no valor inicial do contrato. Está naquilo que não parecia tão visível quando a decisão foi tomada.

Está em:

• manutenção mais cara do que deveria
• lentidão para ajustar
• baixa flexibilidade
• dependência do fornecedor
• dificuldade de integração
• necessidade constante de contorno
• operação absorvendo desgaste que a tecnologia deveria reduzir

É por isso que o fornecedor errado muitas vezes não parece caro no começo. Ele parece caro depois, quando a empresa precisa conviver com a estrutura que comprou.

A empresa demora para perceber porque o problema é gradual

Se o sistema simplesmente quebrasse inteiro no primeiro dia, talvez o erro ficasse mais evidente.

Mas não é assim que normalmente acontece.

O projeto entra no ar. O time se adapta. A operação contorna. O fornecedor responde algumas demandas. O produto segue existindo.

E o desgaste vai sendo absorvido aos poucos.

Esse tipo de custo é perigoso justamente porque não vem sempre com um grande alerta visível. Ele vai se acumulando em atraso, retrabalho, lentidão, dependência e baixa confiança.

É uma lógica próxima do que eu tratei em o app não fracassa no lançamento. Ele fracassa na rotina.. O problema raramente se anuncia no começo. Ele vai se tornando visível quando a rotina força a estrutura a mostrar o que ela realmente é.

O problema não está só no fornecedor. Está no critério de escolha.

Também vale dizer isso com clareza.

Em muitos casos, a empresa escolhe mal porque faz as perguntas erradas.

Olha demais para:

• preço inicial
• prazo de entrega
• apresentação comercial
• conforto do processo de venda

E olha de menos para:

• sustentação
• operação
• integração
• governança de evolução
• qualidade da arquitetura
• capacidade real de manter o produto saudável depois

Então, no fundo, o preço do fornecedor errado aparece depois porque o critério de contratação também estava errado antes.

Fornecedor melhor evita custo invisível antes de ele nascer

É isso que um parceiro melhor costuma fazer.

Não entrega só código.

Ajuda a evitar decisões ruins no começo. Ajuda a enquadrar melhor o escopo. Ajuda a pensar integração com mais maturidade. Ajuda a estruturar manutenção de forma menos improvisada. Ajuda a construir algo mais sustentável, e não apenas algo apresentável.

É por isso que, em tecnologia, o fornecedor melhor nem sempre é o que parece mais barato na largada. Muitas vezes, ele é justamente o que custa menos na convivência com o projeto inteiro.

Projeto entregue não significa problema resolvido

Eu gosto de insistir nesse ponto porque ele muda muito a qualidade da decisão.

A empresa precisa parar de tratar entrega como sinônimo de sucesso.

Projeto entregue pode ser só o começo de um problema que ainda não apareceu por completo.

Se a solução entra no ar, mas nasce cara de manter, lenta de evoluir, difícil de integrar e dependente demais de quem construiu, a entrega não resolveu tanto quanto parecia.

Conclusão

No fim, o fornecedor errado custa na vida real do produto.

• custa na operação
• custa na manutenção
• custa na evolução
• custa na margem
• custa na velocidade
• custa na energia do time

E custa principalmente na ilusão de que a empresa resolveu um problema quando, na verdade, só empurrou a parte mais cara dele para depois.

Por isso, eu desconfio sempre de projeto que parece barato demais antes de viver a rotina.

Porque, em tecnologia, o preço do fornecedor errado quase nunca aparece na assinatura do contrato. Ele aparece depois que o projeto parece entregue.