O Que Perguntar Para Desenvolvedor Freelancer Antes de Fechar

Chegar à conversa final com um desenvolvedor freelancer sem saber o que perguntar é o caminho mais curto para um projeto problemático. Não porque o profissional seja necessariamente ruim, mas porque perguntas erradas ou ausentes deixam lacunas que viram conflito depois: prazo estourado sem aviso, escopo que “não estava incluído”, código entregue que ninguém além do autor consegue manter.

Já estive dos dois lados dessa negociação. Como desenvolvedor, sei quais perguntas me fazem confiar que o cliente vai ser um bom parceiro de projeto. Como quem acompanha gestores contratando, sei quais perguntas revelam o que o portfólio não mostra e o que a conversa inicial esconde.

Este artigo é uma lista comentada das perguntas que realmente importam, na ordem em que fazem mais sentido dentro de uma conversa de avaliação. Cada pergunta vem com a explicação do porquê ela importa e o que a resposta do profissional revela sobre ele.

Antes de Fazer Qualquer Pergunta: O Que Você Precisa Ter Claro

Nenhuma pergunta funciona sem um briefing mínimo do seu lado. Antes de avaliar um desenvolvedor, você precisa conseguir responder:

Qual problema de negócio o projeto resolve? Não a funcionalidade técnica, o problema real. “Preciso de um sistema” não é briefing. “Nosso time de vendas perde negócios porque não consegue acompanhar o funil em tempo real e o CRM atual não integra com nossa ferramenta de e-mail” é um briefing.

Qual é o prazo que você tem e por quê? Prazos arbitrários criam pressão sem propósito. Prazos com justificativa de negócio (lançamento em evento, temporada de vendas, integração com outra entrega) são critérios reais que o desenvolvedor precisa conhecer.

Qual é o orçamento disponível? Não precisa revelar o número imediatamente, mas precisa saber se está avaliando um projeto de R$ 5 mil ou de R$ 50 mil, porque os profissionais e as soluções adequadas são completamente diferentes.

Com isso claro, as perguntas abaixo funcionam. Sem isso, você vai receber respostas genéricas para um briefing genérico.

As Perguntas Que Revelam o Nível Real do Profissional

1. “Depois de ouvir o que preciso, quais são suas dúvidas antes de fazer uma estimativa?”

Essa é a primeira pergunta e a mais reveladora de todas, porque você não está perguntando nada diretamente. Está criando espaço para o profissional demonstrar como raciocina.

Um desenvolvedor sênior vai ter perguntas organizadas sobre o negócio, os usuários do sistema, as integrações necessárias, as restrições técnicas existentes e os critérios de sucesso. Ele vai querer entender antes de estimar.

Um profissional menos experiente ou menos honesto vai dar uma estimativa imediata, sem perguntas, para não parecer inseguro ou para não perder o cliente. Essa estimativa vai estar errada, e você vai descobrir no meio do projeto.

Se o profissional não faz perguntas antes de estimar, essa é informação suficiente para encerrar a avaliação.

2. “Como você divide um projeto em etapas de entrega?”

Essa pergunta revela se o profissional trabalha com processo ou trabalha no escuro.

A resposta que você quer ouvir inclui alguma forma de entrega incremental: uma primeira versão funcional com as funcionalidades principais, seguida de ciclos de revisão e expansão. Os princípios ágeis de entrega de software têm décadas de evidência mostrando que entregas menores e frequentes reduzem risco e aumentam qualidade. Um profissional que internalizou isso vai falar sobre isso naturalmente.

A resposta que indica problema é “entrego o projeto completo no final”. Isso significa que você vai ficar sem visibilidade por semanas ou meses, sem possibilidade de ajuste no meio do caminho, e vai receber o resultado final com pouco tempo para correções antes do prazo.

3. “Em que frequência e formato você vai me atualizar sobre o progresso?”

Gestão de projeto não é microgestão. É visibilidade. Você não precisa saber o que o desenvolvedor está fazendo a cada hora, mas precisa saber o que foi entregue na semana, o que está planejado para a próxima e o que está travado.

A resposta que você quer ouvir tem frequência definida (semanal é o padrão razoável para a maioria dos projetos), canal definido (e-mail, mensagem, reunião curta) e conteúdo definido (o que foi feito, o que vem a seguir, o que precisa de decisão da sua parte).

A resposta que indica problema é “pode me chamar quando quiser” sem estrutura proativa. Isso transfere para você a responsabilidade de ficar perguntando, e o profissional vai responder quando tiver algo positivo para mostrar, não quando tiver impedimentos para comunicar.

4. “O que acontece se surgir algo mais complexo do que o previsto e o prazo for impactado?”

Todo projeto tem surpresas. A questão não é se vai surgir algo imprevisto, é como o profissional lida quando surge.

A resposta que você quer ouvir inclui comunicação imediata quando o impedimento é identificado, não quando o prazo já estourou. Inclui apresentação das opções disponíveis: reduzir escopo para cumprir o prazo, estender o prazo mantendo o escopo, ou priorizar o que é mais crítico para uma primeira entrega. Inclui o profissional assumindo responsabilidade pela comunicação proativa, não esperando você perguntar.

A resposta que indica problema é qualquer minimização: “não costumo ter atrasos”, “se aparecer algo a gente resolve na hora”, “nunca tive esse problema”. Projetos reais sempre têm imprevistos. Um profissional que nega isso ou não tem processo para lidar é um risco que vai se materializar no pior momento.

5. “Como você trata mudanças de escopo que surgem durante o projeto?”

Mudanças de escopo são inevitáveis. A pergunta não é se vão acontecer, é como são gerenciadas.

A resposta que você quer ouvir descreve um processo claro: a mudança é documentada, o impacto no prazo e no custo é avaliado e comunicado antes de ser implementado, e você aprova antes de o trabalho começar. Nenhuma mudança deveria ser simplesmente absorvida sem análise, e nenhuma deveria ser cobrada sem aviso.

A resposta que indica problema tem dois extremos igualmente ruins: “faço qualquer mudança sem custo adicional” (o profissional não tem processo e vai acumular trabalho não pago até o projeto se tornar insustentável) ou “qualquer mudança gera um novo orçamento” sem critério claro sobre o que é mudança e o que é refinamento do escopo original.

6. “Como você documenta o que está sendo construído?”

Documentação é o que garante que o projeto não vai ficar refém do profissional que o construiu.

A resposta que você quer ouvir menciona pelo menos comentários no código para partes complexas, um documento de arquitetura explicando as decisões principais, e instruções de como configurar e rodar o projeto em um ambiente novo. Isso garante que outro desenvolvedor consiga dar continuidade ao trabalho se necessário.

A resposta que indica problema é “o código é auto-documentado” ou silêncio. Código auto-documentado é um ideal que raramente se sustenta em projetos reais. E um projeto sem documentação é um projeto que vai custar caro para qualquer desenvolvedor que tocar depois.

A entrega incremental na prática descrita pelo Martin Fowler reforça que documentação não é burocracia, é parte do que constitui uma entrega de qualidade.

7. “Você pode me dar contato de dois clientes anteriores para referência?”

Referências verificáveis são a evidência mais concreta de histórico real. Qualquer profissional com entregas sólidas vai ter clientes que podem ser contatados e que têm algo positivo a dizer.

Quando receber os contatos, ligue ou mande mensagem com três perguntas: o projeto foi entregue no prazo? A comunicação durante o projeto foi boa? Você contrataria novamente?

Se o profissional não tem referências disponíveis, peça o motivo. Pode ser que trabalhe principalmente com NDA (acordos de confidencialidade), o que é legítimo, mas deve ser explicado. Resistência em fornecer referências sem justificativa é um sinal de alerta.

8. “Como funciona o processo de entrega do código ao final do projeto?”

Essa pergunta garante que você vai receber o que pagou da forma que pode usar.

A resposta que você quer ouvir inclui acesso ao repositório de código (de preferência no GitHub, GitLab ou Bitbucket, com você como dono do repositório, não o desenvolvedor), documentação de como fazer o deploy e configurar o ambiente, e um período de suporte pós-entrega para ajustes que surgem nos primeiros dias de uso real.

A resposta que indica problema é qualquer situação em que o código fica “com o desenvolvedor” até o pagamento final, ou em que você recebe apenas o projeto rodando em um servidor sem acesso ao código-fonte. O código é seu. Você deve ter acesso a ele durante todo o projeto, não apenas ao final.

9. “O que está fora do escopo do que você propôs?”

Essa pergunta elimina a maior fonte de conflito em projetos de desenvolvimento: o “eu achei que estava incluído”.

Um bom profissional vai listar explicitamente o que não está incluído na proposta: integrações específicas que não foram mencionadas, suporte pós-entrega além de um período definido, treinamento de uso, criação de conteúdo ou design que não é responsabilidade do desenvolvedor.

Essa clareza protege os dois lados. Você sabe exatamente pelo que está pagando. O profissional sabe exatamente pelo que está sendo contratado.

10. “Como você lida com projetos que têm prazo fixo não negociável?”

Se o seu projeto tem um prazo real e fixo, essa pergunta é crítica.

A resposta que você quer ouvir é honesta sobre as implicações: para cumprir um prazo fixo, o escopo pode precisar ser reduzido. O profissional vai trabalhar com você para definir o que é essencial para o prazo e o que pode vir depois. Ele não vai prometer tudo no prazo apenas para fechar o contrato.

A resposta que indica problema é a promessa incondicional: “sem problema, faço tudo no prazo que você precisa” sem análise do escopo. Essa promessa vai ser cumprida de duas formas: com qualidade comprometida ou com horas extras que vão ser cobradas no final como “fora do escopo”.

Perguntas Sobre o Contrato e a Forma de Trabalho

11. “Como você prefere estruturar o pagamento?”

Pagamento é onde expectativas desalinhadas viram conflito financeiro. A estrutura mais comum e mais saudável para projetos com escopo definido é pagamento por marcos de entrega: uma entrada no início, pagamentos intermediários conforme etapas são entregues e validadas, e o saldo final na entrega completa.

Desconfie de dois extremos: profissionais que pedem 100% adiantado (você perde alavancagem para garantir a entrega) e profissionais que aceitam 100% no final (eles assumem um risco que pode comprometer a qualidade quando percebem que o projeto ficou maior do que o previsto).

12. “A quem pertence o código ao final do projeto?”

Essa é uma pergunta jurídica disfarçada de técnica. A resposta correta é que o código pertence integralmente a você, o cliente, após o pagamento completo. Isso deve estar explícito no contrato.

Alguns profissionais reutilizam componentes que desenvolveram em projetos anteriores. Isso é prática comum e aceitável, mas você precisa saber o que é desenvolvido especificamente para o seu projeto e o que é componente reutilizado. Componentes reutilizados têm implicações de licença que precisam ser entendidas.

Como Usar Essas Perguntas na Prática

Você não precisa fazer todas as perguntas em uma única reunião. Distribua em momentos diferentes do processo de avaliação.

Na primeira conversa, foque nas perguntas sobre processo de trabalho e na observação das perguntas que o profissional faz sobre o seu projeto. Essa conversa serve para avaliar compatibilidade de comunicação.

Ao analisar a proposta escrita, verifique se as perguntas sobre escopo, entregas e pagamento estão respondidas implicitamente no documento. Uma proposta bem estruturada já responde várias dessas questões sem você precisar perguntar.

Antes de assinar, faça as perguntas sobre contrato, propriedade do código e referências. Essas são as questões que precisam de resposta formal antes de qualquer compromisso financeiro.

Entender como trabalho como desenvolvedor freelancer pode te dar uma referência de como um profissional com processo estruturado responde a essas perguntas na prática.

Antes de chegar às perguntas, vale também entender como definir o escopo antes de qualquer conversa para que as respostas que você receber façam sentido no contexto do que você realmente precisa. E depois de fechar, saiba como estruturar o contrato com segurança para proteger o projeto do início ao fim.

O Que as Respostas Dizem Sobre Você Também

Uma última perspectiva que raramente aparece nesse tipo de guia: as perguntas que você faz dizem para o desenvolvedor que tipo de cliente você vai ser.

Um gestor que chega com briefing claro, perguntas organizadas e interesse genuíno no processo de trabalho atrai profissionais melhores e tem mais poder de negociação. Um gestor que chega apenas com “quanto custa e quando fica pronto” vai receber estimativas genéricas e vai contratar com base em preço, que é o critério menos confiável de todos.

Profissionais seniores escolhem os projetos em que trabalham. Quando você demonstra que sabe o que está avaliando, você se torna o tipo de cliente que eles querem ter.

Conclusão

Contratar um desenvolvedor freelancer sem as perguntas certas é um jogo de sorte. Com as perguntas certas, vira um processo de avaliação que você consegue conduzir mesmo sem background técnico, porque o que você está avaliando não é código. É processo, comunicação, honestidade e histórico de entrega.

As perguntas deste artigo são o filtro que separa profissionais que vão entregar do que foi combinado dos que vão criar problemas que você só vai descobrir no meio do projeto.

Se você está chegando ao final desse processo de avaliação e quer entender como contratar sem depender do TI para avaliar, o artigo anterior do cluster cobre exatamente os critérios de avaliação de senioridade que complementam as perguntas deste guia.