Como contratar um desenvolvedor ou consultoria de software sem cair em armadilhas

Quase toda história ruim de contratação de software tem um ponto em comum: os sinais estavam lá antes do contrato. O orçamento que chegou rápido demais, a proposta de meia página, o repositório que “depois a gente passa”. Na hora, pareciam detalhes.

Meses depois, viram um sistema pela metade, sem código, sem acesso e sem ninguém para responder. E a empresa percebe que pagou por algo que não controla.

Se você ainda está decidindo o modelo de contratação, leia freelancer sênior vs. software house. Se já escolheu e quer conferir as cláusulas, o checklist para contratar um desenvolvedor PJ cobre o contrato. Aqui o foco é outro: reconhecer a armadilha antes de cair nela e saber o que pedir em cada caso.

Quais sinais de alerta aparecem já na negociação?

A negociação é o momento em que o fornecedor está mais motivado a causar boa impressão. Se algo já parece estranho agora, dificilmente vai melhorar depois da assinatura.

O fornecedor some antes mesmo de fechar

Se ele demora dias para responder enquanto ainda quer vender, imagine depois de receber a entrada. Observe o tempo de resposta, se existe um canal definido e se os combinados ficam registrados por escrito. O desenvolvedor que some no meio do projeto quase sempre deu sinais na negociação.

O orçamento chegou sem nenhuma pergunta

Um preço fechado depois de uma mensagem de três linhas não é agilidade, é chute. Ou o fornecedor vai cobrar aditivos a cada detalhe, ou vai entregar a versão mais simples do que ele imaginou, que raramente é o que você precisa.

Orçamento sério vem depois de um diagnóstico: perguntas sobre o processo, os usuários, as integrações e o volume de uso.

O preço está muito abaixo dos outros

Diferença de preço entre fornecedores é normal. Mas quando uma proposta custa uma fração das demais para o mesmo escopo, alguma coisa ficou de fora: testes, documentação, suporte, segurança ou as horas reais de trabalho.

Pergunte o que está incluído e o que não está. Os fatores que formam o preço de um sistema estão em quanto custa desenvolver um sistema sob medida.

A proposta não tem escopo

“Desenvolvimento de sistema completo de gestão” não é escopo. Escopo lista as funcionalidades, os perfis de usuário, as integrações, o que fica de fora e como mudanças serão tratadas. Sem isso, não há como cobrar a entrega nem saber se o preço é justo.

Ele sabe tudo de tudo

Site, aplicativo, inteligência artificial, infraestrutura, design e marketing, tudo com a mesma confiança. Um profissional sênior conhece os próprios limites e diz com clareza o que faz, o que terceiriza e o que não recomenda. Quem nunca diz “isso não é comigo” costuma descobrir o limite no seu projeto.

Não tem contrato nem nota fiscal

“A gente fecha pelo WhatsApp” parece prático até dar problema. Sem contrato, não há escopo cobrável, prazo, propriedade do código nem regra para rescisão. Sem nota fiscal, não há sequer como comprovar a relação. Um fornecedor profissional emite nota e assina contrato sem resistência.

Quais sinais indicam que a entrega vai virar uma caixa-preta?

Caixa-preta é o projeto em que você paga, espera e só descobre o resultado no fim. Três sinais denunciam esse risco.

Não há entregas intermediárias

Se o plano é “em quatro meses eu te mostro pronto”, você só vai descobrir um atraso ou um desalinhamento no quarto mês. Projetos saudáveis mostram software funcionando em ciclos curtos, em um ambiente de testes que você consegue abrir e usar.

Ninguém testa

Pergunte como o sistema é testado antes de chegar até você. Se a resposta for “o cliente testa”, a sua equipe vira o controle de qualidade, e os erros aparecem em produção, na frente do seu cliente. Testes nas regras críticas e uma rodada de validação antes de cada entrega são o mínimo.

O júnior escondido atrás do sênior que vendeu

A reunião comercial é com alguém experiente; o código é escrito por outra pessoa, que você nunca conheceu. Equipes com profissionais em níveis diferentes são normais. O problema é não saber.

Pergunte quem, nominalmente, vai desenvolver, quem revisa o código e com quem você fala no dia a dia.

Como saber se o sistema vai ser realmente da sua empresa?

Esta é a armadilha mais cara, porque só aparece quando a relação termina. Enquanto tudo vai bem, ninguém pergunta em nome de quem as coisas estão.

O código e os acessos ficam com o fornecedor

O repositório, lugar onde o código-fonte fica guardado (como GitHub ou GitLab), está na conta pessoal do desenvolvedor. As senhas do servidor, do banco de dados e dos serviços também. Quando a parceria acaba, a empresa descobre que pagou por um sistema que não consegue nem acessar.

A hospedagem e o domínio estão no nome do fornecedor

É a mesma armadilha, em outra camada. Se a conta da nuvem, o domínio ou os serviços pagos estão no CPF ou no CNPJ do fornecedor, é ele quem controla se o seu sistema fica no ar. Trocar de fornecedor vira uma negociação em que você não tem poder.

Não existe documentação

Sem uma documentação mínima (como instalar, como publicar uma nova versão, quais são as integrações, onde ficam as credenciais), qualquer outro profissional vai gastar muito tempo só para entender o que existe. E esse tempo você paga. Documentação é o que torna o sistema transferível.

O que pedir para cada sinal de alerta?

Use esta tabela como guia rápido durante a negociação:

Sinal de alerta	O que pedir
Demora para responder e combinados soltos	Canal oficial, prazo de resposta combinado e decisões registradas por escrito
Orçamento sem diagnóstico	Uma conversa de levantamento antes do preço, com perguntas sobre processo, usuários e integrações
Preço muito abaixo dos outros	Lista do que está incluído e do que não está: testes, documentação, publicação e suporte
Proposta sem escopo	Escopo com funcionalidades, perfis de usuário, integrações, itens fora do escopo e regra para mudanças
“Sabe tudo de tudo”	Exemplos de projetos parecidos com o seu e clareza sobre o que será terceirizado
Sem contrato ou nota fiscal	Contrato PJ assinado, CNPJ ativo e nota fiscal a cada pagamento
Nenhuma entrega intermediária	Cronograma com marcos e demonstração do software funcionando a cada ciclo
Ninguém testa	Explicação de como o sistema é testado e um ambiente de homologação (de testes) para você validar
Júnior escondido	Nome de quem desenvolve e de quem revisa, com contato direto com essas pessoas
Código com o fornecedor	Repositório em conta da sua empresa desde o primeiro dia
Hospedagem e domínio no nome dele	Nuvem, domínio e serviços no CNPJ da sua empresa, com o fornecedor como convidado
Sem documentação	Documentação mínima como item de entrega, atualizada a cada marco

Como se proteger antes e durante o projeto?

Proteção não é desconfiança: é organização. Os pontos abaixo funcionam com qualquer fornecedor, do freelancer à consultoria.

Contrato com escopo e marcos

O contrato deve anexar o escopo e dividir o projeto em marcos com critério de aceite, ou seja, o que precisa estar funcionando para aquele marco ser considerado entregue. As cláusulas essenciais estão no checklist para contratar um desenvolvedor PJ.

Repositório, nuvem e domínio em nome da empresa

Na prática, crie você mesmo uma organização no GitHub ou no GitLab em nome da empresa e convide o desenvolvedor. Faça o mesmo com a conta da nuvem, o domínio e os serviços pagos.

Use um e-mail corporativo genérico, como ti@suaempresa.com.br, e não o e-mail pessoal de ninguém. O fornecedor trabalha como convidado; a chave é sua.

Acessos administrativos com a empresa

Guarde as credenciais de administrador em um gerenciador de senhas da empresa. O fornecedor recebe acessos com a permissão necessária para trabalhar, e você consegue revogá-los rapidamente se a relação terminar.

Demonstrações a cada ciclo

Combine uma demonstração ao fim de cada ciclo de trabalho, com o software rodando, não com slides. É nessa reunião que os desalinhamentos aparecem cedo, quando ainda são baratos de corrigir.

Pagamentos atrelados a entregas

Estruture os pagamentos por marco aprovado, e não só por calendário: uma entrada para iniciar e as parcelas seguintes liberadas conforme cada marco cumpre o critério de aceite. Assim, o dinheiro acompanha o progresso real.

Documentação e suporte depois da entrega

Inclua a documentação como entregável de cada marco. E defina, antes de começar, como será o suporte depois que o sistema entrar no ar: quem corrige erros, em quanto tempo, o que está incluído e o que é cobrado à parte.

LGPD e NDA

Se o sistema vai tratar dados pessoais de clientes ou funcionários, na linguagem da LGPD a sua empresa é a controladora e o fornecedor que trata esses dados em nome dela é o operador. O contrato precisa prever confidencialidade, uso dos dados só para a finalidade do projeto e o que acontece com eles no fim da relação.

Um NDA (acordo de confidencialidade) assinado antes de compartilhar regras de negócio sensíveis completa a proteção.

Que perguntas fazer na primeira reunião?

As respostas dizem muito mais do que o portfólio. Compare o que você ouvir com esta tabela:

Pergunta	Resposta que tranquiliza	Resposta que preocupa
Quem vai escrever o código do meu projeto?	Nomes, papéis e contato direto com quem desenvolve	“A nossa equipe”, sem nomes
Como vou acompanhar o andamento?	Demonstrações periódicas e ambiente de testes que eu posso acessar	“Quando estiver pronto eu te mostro”
Em nome de quem ficam repositório, nuvem e domínio?	“Da sua empresa, desde o primeiro dia”	“Fica comigo e depois eu transfiro”
O que acontece se o escopo mudar?	Regra clara para avaliar, orçar e aprovar mudanças	“A gente vê na hora”
Como o sistema é testado?	Testes nas regras críticas e validação antes de cada entrega	“Você testa e me avisa”
O que está fora da proposta?	Uma lista objetiva do que não está incluído	“Está tudo incluído”
Como funciona o suporte depois da entrega?	Garantia, canal e condições por escrito	“Qualquer coisa, me chama”

Faça também um teste simples: peça que o fornecedor explique, com as palavras dele, o problema que você quer resolver. Se ele não consegue, ainda não entendeu o suficiente para orçar.

Checklist antes de assinar

• Houve uma conversa de diagnóstico antes do orçamento.
• A proposta tem escopo, itens fora do escopo e regra para mudanças.
• Sei o que está incluído no preço: testes, documentação, publicação e suporte.
• Sei quem vai desenvolver e tenho contato direto com essa pessoa.
• O cronograma tem marcos com critério de aceite e demonstrações.
• Os pagamentos estão atrelados a marcos aprovados.
• Repositório, nuvem e domínio estão, ou ficarão desde o início, em nome da empresa.
• As credenciais de administrador estão com a empresa.
• A documentação faz parte das entregas.
• O suporte depois da entrega está definido por escrito.
• Contrato PJ, nota fiscal, NDA e cláusulas de LGPD estão previstos.

Como eu evito essas armadilhas nos meus projetos?

Não existe fornecedor perfeito, mas existe fornecedor transparente. Nos meus projetos, a regra é esta:

• Contato direto com quem desenvolve. Quem conversa o escopo com você é quem escreve o código.
• Entregas incrementais com demonstração. Você vê o sistema funcionando a cada ciclo, não só no fim.
• Código e documentação ficam com o cliente. Repositório e contas em nome da sua empresa.
• Contrato PJ com nota fiscal e NDA. Tudo por escrito, desde o início.

Se você está avaliando propostas e quer uma segunda opinião técnica antes de fechar, esse é o tipo de conversa que cabe na consultoria e arquitetura de software. E se a armadilha já aconteceu e você herdou um sistema sem dono, o ponto de partida é a modernização de sistemas legados.

O diagnóstico inicial é gratuito e dura 30 minutos. Você conta o que precisa, eu faço as perguntas que um orçamento sério exige e você sai sabendo o que pedir, comigo ou com qualquer outro fornecedor.