Checklist para contratar um desenvolvedor PJ

Contratar um desenvolvedor PJ para tocar o sistema da sua empresa é mais simples do que abrir uma vaga CLT, mas isso não significa que deva ser informal. Sem os pontos certos por escrito, sua empresa fica exposta a riscos que só aparecem quando já é tarde: código sem dono, prazo sem compromisso, escopo que nunca acaba.

Este é o checklist que eu mesmo sigo em todo projeto que assino. Ele serve para o dono da empresa, para o gestor que vai acompanhar o projeto e para quem vai formalizar a contratação no RH ou no jurídico.

1. Contrato por escrito, sempre

Nunca comece um projeto por “combinado” verbal ou troca de mensagens solta. O contrato deve conter, no mínimo:

• Escopo detalhado do que será entregue (e do que não está incluso).
• Prazo e marcos de entrega intermediários, não só a data final.
• Valor e forma de pagamento: à vista, por marco ou mensal, no caso de squad dedicado.
• Cláusula de rescisão e o que acontece com o código já entregue se o contrato for encerrado antes do fim.

A diferença entre um escopo bom e um ruim está no detalhe. Imagine uma clínica que contrata “um sistema de agendamento”. Isso não é escopo. Escopo é: agenda por profissional, cadastro de pacientes, controle de retornos e relatório mensal de atendimentos, com acesso pelo navegador. E, na lista do que não está incluso: aplicativo para celular e integração com convênios.

Quando o que fica de fora está escrito, a conversa “mas eu achei que vinha junto” simplesmente não acontece.

2. Propriedade do código

Isso parece óbvio, mas é o ponto mais negligenciado. O contrato precisa deixar explícito que todo o código, documentação e ativos produzidos são de propriedade da sua empresa após o pagamento, incluindo repositórios, credenciais de infraestrutura e acessos administrativos. Peça a transferência formal de repositório (não apenas acesso de colaborador) ao final do projeto ou de cada marco pago.

Na prática, confira se estes itens estão em nome da empresa, e não do desenvolvedor:

• repositório do código (GitHub, GitLab ou similar);
• conta de nuvem ou hospedagem onde o sistema roda;
• domínio e certificados;
• banco de dados e rotina de backup;
• contas de serviços integrados, como e-mail transacional, gateway de pagamento ou API de mensagens.

O caminho mais seguro é a empresa criar essas contas desde o início e dar acesso ao desenvolvedor, e não o contrário. Assim, se o contrato acabar, basta revogar o acesso.

3. NDA (acordo de confidencialidade)

Se o projeto envolve dados de clientes, regras de negócio sensíveis ou vantagem competitiva, um NDA assinado antes de qualquer detalhe ser compartilhado é básico, e qualquer desenvolvedor sênior sério vai assinar sem resistência.

Se o desenvolvedor vai ter acesso a dados pessoais (de clientes, pacientes ou funcionários), vá além do NDA: defina no contrato como esses dados podem ser usados, armazenados e descartados, em linha com a LGPD. Um bom profissional também vai propor acesso mínimo: ambiente de testes com dados fictícios sempre que possível e acesso à produção só quando necessário.

4. Nota fiscal e regularidade

Contratação PJ exige nota fiscal de serviço. Verifique se o desenvolvedor tem CNPJ ativo e emite NF corretamente. Isso protege sua empresa em uma eventual fiscalização e é um dos elementos que ajudam a afastar a caracterização de vínculo empregatício.

A consulta do CNPJ é pública e gratuita no site da Receita Federal. Confira se a situação cadastral está ativa e se a atividade registrada é compatível com desenvolvimento de software.

5. Marcos de entrega verificáveis

Projetos “caixa-preta”, em que só se vê o resultado no fim, escondem atraso até ser tarde demais. Exija entregas visíveis em sprints curtos (ciclos de trabalho de poucas semanas): ambiente de homologação atualizado, changelog ou reuniões de demonstração periódicas.

Veja um exemplo de como amarrar pagamento a entregas em um sistema de ordem de serviço hipotético:

1. Marco 1: cadastro de clientes e equipamentos funcionando em homologação.
2. Marco 2: abertura, andamento e fechamento de OS, com status visível para a equipe.
3. Marco 3: relatórios, permissões de usuário e publicação em produção.

Cada marco só é pago depois que você testou e aprovou. Isso protege os dois lados: você paga pelo que viu funcionando, e o desenvolvedor recebe de forma regular.

6. O que perguntar antes de fechar

1. Quem mais vai tocar no código além de você? (Importante saber se é você mesmo entregando ou se vai repassar para terceiros.)
2. Como funciona o suporte pós-entrega: está incluso ou é cobrado à parte?
3. O que acontece se o escopo mudar no meio do projeto?
4. Quais tecnologias serão usadas e por quê? Veja se fazem sentido para o problema, não para o currículo do desenvolvedor.
5. Posso ver um sistema seu em produção ou conversar com alguém que já contratou você?
6. Como vou acompanhar o andamento, e com que frequência?

Quais sinais de alerta devem fazer você desistir?

Alguns comportamentos, logo no início, dizem muito sobre como o projeto vai terminar:

• recusa em assinar contrato ou NDA;
• pedido de pagamento integral adiantado, sem marcos;
• valor fechado sem nenhuma conversa sobre o escopo;
• código e acessos que só serão entregues “no final”;
• falta de CNPJ ou de nota fiscal.

Um único item já justifica uma conversa franca. Dois ou mais, e o mais barato costuma ser procurar outro profissional. Para um roteiro completo de avaliação de propostas, veja como contratar um desenvolvedor ou consultoria sem cair em armadilhas.

Checklist resumido: o que conferir antes de assinar

Item	O que exigir	Risco se faltar
Contrato	Escopo, o que não está incluso, prazo, valor e rescisão	Escopo infinito e discussão sobre o que foi combinado
Propriedade do código	Cessão do código e transferência de repositório e acessos	Sistema pago que não é da sua empresa
NDA e dados pessoais	Confidencialidade e regras de uso de dados, em linha com a LGPD	Vazamento de regra de negócio ou de dados de clientes
Nota fiscal	CNPJ ativo e NF de serviço a cada pagamento	Problema fiscal e risco trabalhista
Marcos de entrega	Entregas testáveis em ciclos curtos, com pagamento por marco	Atraso descoberto só no fim
Suporte	Regras de suporte pós-entrega por escrito	Custo surpresa depois da entrega
Mudança de escopo	Processo definido para aprovar e orçar mudanças	Prazo e orçamento sem controle

Se você ainda está decidindo o formato da contratação, vale ler freelancer sênior vs. software house: qual contratar. E, se precisa de apoio técnico para avaliar propostas de outros fornecedores ou revisar um projeto em andamento, a consultoria de arquitetura de software cobre exatamente isso.

Se você já tem um projeto em mente e quer proposta com escopo, contrato, NDA e nota fiscal desde o primeiro contato, fale comigo: o diagnóstico é gratuito. Se o motivo da contratação é substituir um sistema antigo, veja também os sinais de que é hora de refatorar o legado.