As propostas que você está comparando foram escritas pra parecer iguais. Estas são as perguntas que eu faria antes de assinar com qualquer fornecedor de software — incluindo a gente.

Assinado: José Ribeiro, sócio da Bleu

Nas últimas semanas eu estudei como mais de cem software houses e consultorias se apresentam: site, proposta, anúncio, LinkedIn. Quase todas dizem a mesma coisa. Time sênior. Metodologia ágil. IA. Centenas de projetos entregues.

Isso não é preguiça: promessa específica é promessa que pode ser cobrada depois, então o texto genérico é a escolha segura. É por isso que três propostas na sua mesa parecem a mesma empresa com três logos diferentes. Quando tudo parece igual, o único critério visível que sobra é o preço. E preço é o pior critério pra decidir quem vai mexer no sistema que sustenta a sua operação.

O que segue é a lista que eu usaria no seu lugar. Use contra qualquer fornecedor, incluindo a gente.

**1. Quem vai escrever o código?** Peça pra conhecer os engenheiros do projeto antes de assinar. O time comercial você já conhece. Se a empresa não deixa, é porque o time da proposta e o time da entrega são coisas diferentes.

**2. Quantos do time proposto são seniores de verdade?** “Time sênior” descreve a proposta; quem descreve a entrega é a lista de nomes. Pergunte nome por nome, e pergunte se essas pessoas seguem no projeto depois do terceiro mês.

**3. Quem responde quando der errado?** Um nome, não um cargo. Projeto de software dá errado em algum momento. O que separa fornecedores é quem aparece quando isso acontece.

**4. Dos “500 projetos entregues”, quais três são parecidos com o meu?** Contador de projeto é o padrão do mercado justamente porque ninguém verifica. Peça três casos parecidos com o seu, com nome e resultado, e pergunte o que dá pra checar.

**5. Posso falar com um cliente?** Uma pessoa, com telefone — a parede de logos não conta. Um logo no site diz que houve contrato; se o projeto foi bem, só o cliente conta.

**6. Posso ver um repositório de verdade?** Um projeto open source, ou um repositório real com autorização do cliente. O código diz o que a proposta esconde: como o time nomeia as coisas, testa, documenta e decide.

**7. Me mostra uma decisão difícil que vocês tomaram?** Um documento de decisão real, anonimizado se precisar. Um time que decide bem consegue mostrar como decidiu. Se não tem nada registrado, é porque as decisões saem no improviso.

**8. Como vocês precificam mudança de escopo?** Em contrato de escopo fechado, a margem mora no aditivo: o preço inicial ganha a concorrência, a mudança paga o projeto. Se a resposta pra essa pergunta for vaga, você descobriu o modelo de negócio.

**9. O que vocês se recusariam a construir?** Quem nunca recusa nada não tem critério, e vai aceitar o seu pedido mesmo quando o pedido estiver errado. Peça exemplos do que já recusaram.

**10. O que deste escopo eu NÃO deveria contratar agora?** A proposta média maximiza o escopo. Um parceiro de verdade consegue apontar o que pode esperar, mesmo custando dinheiro pra ele.

**11. Se eu sair em seis meses, o que levo comigo?** Propriedade do código, acesso à infra, documentação, contas em nome de quem. O custo de sair se define no dia de assinar, não no dia de sair.

**12. Quem fica com o conhecimento quando o contrato acaba?** Se a resposta depender de uma pessoa continuar lá, você está alugando memória. Pergunte como o conhecimento vira coisa que fica: código, documento, processo.

Seria fácil terminar o texto aqui e deixar implícito que a Bleu passa em tudo. Vou responder às que mais separam fornecedor de parceiro.

Se você está comparando propostas agora, uma conversa de 30 minutos ajuda mais que qualquer texto: você traz as propostas, a gente traz as perguntas.

Contato: [Agendar 30 minutos](https://bleu.builders/pt/contact/)