17 abr 2026 · Checklist · 6 min de leitura

Checklist pra escolher um desenvolvedor sem se arrepender

Contratar desenvolvedor errado custa caro de três formas: dinheiro que você paga e perde, tempo que você investe e não volta, e credibilidade com seu próprio cliente, que vê sistema quebrado. Esse checklist de 11 perguntas separa o profissional do amador em uma reunião só. Imprime, leva e aplica.

Antes das perguntas: como conduzir a conversa

As perguntas abaixo funcionam melhor quando você faz em sequência, anota a resposta e observa reação. Amador trava, inventa ou fica nervoso. Profissional responde com naturalidade e até complementa informação que você nem pediu. Não precisa ser interrogatório — conversa fluida, com as perguntas aparecendo em momentos adequados.

Pergunta 1: você tem CNPJ e emite nota fiscal?

Por que importa: sem CNPJ, você não tem segurança jurídica nenhuma. Qualquer problema vira discussão pessoal. Empresa pequena que compra de CPF não consegue deduzir despesa, perde oportunidade em licitação e corre risco fiscal.

Resposta esperada: "Sim, CNPJ ativo desde X, emito NFS-e." Se titubeou ou disse "posso emitir pelo MEI de um amigo", alerta vermelho.

Pergunta 2: posso ver 3 projetos que você fez nos últimos 12 meses?

Por que importa: portfólio velho mostra que o cara parou ou virou revendedor. Projetos recentes mostram que está ativo, com stack atualizada, e que entrega.

Resposta esperada: links funcionando pra sistemas reais, com breve descrição do que foi entregue. Se só mostra screenshot antigo ou fala "posso mostrar depois", o projeto pode não existir.

Pergunta 3: posso falar com um cliente atual seu?

Por que importa: depoimento em site é fácil de inventar. Cliente real que atende ligação e confirma que está satisfeito, não. Essa simples ligação elimina 90% dos picaretas do mercado.

Resposta esperada: "Posso te passar o contato de dois que autorizam, me dá um dia útil pra avisar eles." Se disser "não posso expor clientes", pergunte por quê — pode ser política legítima, mas geralmente é evasiva.

Pergunta 4: o código fica em repositório privado (GitHub/GitLab) e eu tenho acesso?

Por que importa: se o dev sumir, o código é o único ativo que te sobra. Ter acesso ao repositório desde o primeiro commit garante que, em qualquer cenário, o projeto continua com outra pessoa. Se o código mora só na máquina dele, você é refém.

Resposta esperada: "Sim, crio o repositório no seu GitHub ou GitLab, você fica como owner, eu como colaborador." Se disser "deixo no meu e te mando depois", alerta.

Pergunta 5: qual stack você vai usar e por quê?

Por que importa: dev que sabe o que faz explica escolha técnica com argumento. Dev que bate bumbo de uma linguagem só (e quer usar pra tudo) tende a forçar solução que não encaixa.

Resposta esperada: "Pro seu caso, usaria X porque resolve Y e Z, e porque em Brasília encontro mão de obra pra manter." Se disser "uso a linguagem X sempre", pergunte o que faz em caso diferente.

Pergunta 6: qual é o prazo e como vamos medir progresso?

Por que importa: "um mês" sem marco intermediário é receita pra atraso invisível. Profissional divide em entregas parciais — semana 2 entrega tela de login, semana 4 entrega módulo X. Você vê se está avançando ou se vai estourar.

Resposta esperada: cronograma com marcos semanais ou quinzenais, ambiente de homologação pra você testar cada entrega, reunião curta de alinhamento.

Pergunta 7: como é o pagamento?

Por que importa: dev sério nunca pede 100% adiantado. Pagamento por entrega é o padrão saudável — sinal pra começar (20 a 30%) e o resto atrelado a marcos.

Resposta esperada: "Sinal de X%, restante parcelado por entrega, aceito cartão/PIX/boleto." Se exigir tudo adiantado "pra comprar licença" ou alegar urgência, pisca alerta.

Pergunta 8: o que acontece se eu quiser trocar de dev no meio do projeto?

Por que importa: pergunta desconfortável, mas reveladora. Profissional responde com naturalidade e até te ajuda a transferir.

Resposta esperada: "Código está no seu repositório com documentação, qualquer dev pega a partir dali. Te ajudo na transição se acontecer." Se ficar nervoso ou tentar dissuadir, ele sabe que o código está bagunçado.

Pergunta 9: como fica a manutenção depois de entregue?

Por que importa: sistema não acaba quando é entregue. Bugs aparecem, pequenas mudanças surgem. Se não tem plano de manutenção claro, você vai ficar no limbo ou pagar caro por cada ajuste.

Resposta esperada: "Tenho plano de manutenção mensal a partir de X reais, com SLA de resposta de tantas horas. Se preferir sob demanda, cobro hora X." Se responder "a gente vê depois", alerta.

Pergunta 10: você vai trabalhar sozinho ou tem equipe?

Por que importa: freelance solo tem limite de capacidade. Isso não é ruim — pode ser ótimo pra seu porte de projeto. Mas você precisa saber. Se o cara opera sozinho, pergunte como lida com doença, férias, sobrecarga.

Resposta esperada: honestidade. "Sou solo, tenho rede de colegas pra pico de demanda" é resposta legítima. "Tenho equipe de 20 pessoas" e ele tem 23 anos de idade — desconfia.

Pergunta 11: quando você pode começar?

Por que importa: dev bom tem agenda cheia. Dev que pode começar amanhã sem hesitar, em geral, ou está sem cliente (por que será?) ou está mentindo e vai te enfileirar atrás de outros três projetos.

Resposta esperada: janela realista, tipo "começo semana que vem com X horas dedicadas, entrego Y na data Z". Se prometer começar hoje, é raro que consiga entregar com qualidade.

Sinais extras de alerta (fora das 11)

• Proposta por WhatsApp sem documento escrito.
• Preço muito abaixo da média — em desenvolvimento, barato sempre sai caro.
• Insistência pra "começar hoje com 50% agora" sem contrato assinado.
• Uso exagerado de jargão técnico pra te confundir.
• Recusa a explicar por que vai usar determinada tecnologia.
• E-mail pessoal (@gmail) sem domínio próprio pra uma empresa que se apresenta como "agência".
• Pressão emocional: "se você não fechar hoje, vou fechar com outro".

Como usar esse checklist na prática

Não precisa fazer as 11 perguntas seguidas. Distribua ao longo de uma reunião de 45 minutos, anota as respostas em um Bloco de Notas ou no celular. No fim, releia. Se bateu todas, pode seguir. Se bateu em 2 ou 3 e não ficou satisfeito com a resposta, recue — tem mais dev bom em Brasília, não se vincule por pressa.

Desenvolver sistema é um investimento que vai acompanhar sua empresa por anos. Gastar 45 minutos a mais filtrando é barato comparado ao prejuízo de escolher errado. Leva o checklist, aplica, e você vai distinguir o profissional do enrolão antes de colocar um centavo.