Portfólio de desenvolvedor que gera lead: o que colocar e o que cortar

Você entrega bem. Os projetos funcionam, quem já trabalhou com você recomenda, o código passa em qualquer review. Mas o seu portfólio de desenvolvedor não gera um lead sequer há meses, talvez nunca tenha gerado. Ele existe, tem domínio próprio, lista as suas stacks e aponta para o GitHub. Mesmo assim, quando um cliente em potencial abre a página, fecha em trinta segundos e contrata outra pessoa. Se essa cena parece familiar, este artigo é para você. Vou mostrar o que colocar, o que cortar e como escrever cada seção pensando em quem de fato decide pagar pelo seu trabalho.

A verdade desconfortável sobre o seu portfólio de desenvolvedor

A maioria dos portfólios de dev é escrita para outros devs. Stack em destaque, arquitetura em detalhe, link para repositório. O problema: outro dev quase nunca é quem assina o contrato.

Quem paga é um dono de clínica que quer parar de agendar por WhatsApp, um fundador não técnico com uma ideia de aplicativo, um gerente de operação afogado em planilha. Essa pessoa não sabe o que é React e não deveria precisar saber.

Vou te falar como funciona do lado de quem recebe os leads: na OCA, chegam dezenas de contatos por dia vindos do Google e de assistentes de IA. Quase ninguém pergunta sobre tecnologia. Perguntam se a gente resolve o problema, quanto custa e em quanto tempo fica pronto. Um portfólio que converte responde essas três perguntas antes de a pessoa clicar em qualquer botão.

Cliente não compra código. Compra a confiança de que o projeto vai sair, dentro do prazo, sem sustos. Cada seção do seu portfólio deveria existir para reduzir esse medo. O que não reduz medo é peso morto.

O que colocar no portfólio de desenvolvedor que gera lead

Uma headline que diz para quem você trabalha

Esqueça "desenvolvedor fullstack apaixonado por tecnologia". Isso descreve metade do LinkedIn e não diz nada para quem contrata. A fórmula que funciona tem três partes: o que você constrói, para quem, com que prova.

"Desenvolvo aplicativos e sistemas web para empresas que precisam tirar a operação da planilha. 14 projetos em produção."

Uma frase assim filtra e atrai ao mesmo tempo. Quem não é o seu cliente sai, quem é continua lendo. É exatamente o que uma boa headline deve fazer.

De três a cinco cases contados como história

Não liste features, conte o antes e o depois. Cada case precisa de quatro partes, em linguagem que um leigo entende:

1. Contexto: quem era o cliente e o que estava travado.
2. Problema: o custo real daquilo, em dinheiro, tempo ou clientes perdidos.
3. Solução: o que você construiu, em uma ou duas frases, sem jargão.
4. Resultado: um número. Sempre um número.

Compare "sistema de gestão com Node e PostgreSQL" com "sistema que reduziu de dois dias para duas horas o fechamento mensal de uma distribuidora". O segundo vende. O primeiro é só inventário técnico.

Números, mesmo que aproximados

Quando a gente publica que o Revo, nosso aplicativo de eventos, tem mais de 40 mil usuários e um checkout com 90% de conversão, a conversa com o cliente muda de tom. Número vira prova, e prova encurta negociação. Se você assinou NDA e não pode citar o cliente, use métricas anônimas: "reduzi em 70% o tempo de emissão de notas de uma transportadora". O nome do cliente importa menos que o resultado.

Um caminho de contato sem atrito

Formulário com sete campos é onde lead vai para morrer. Botão de WhatsApp com mensagem pré-preenchida, visível em todas as seções, resolve. O cliente brasileiro decide no WhatsApp, é lá que a conversa precisa começar, não numa caixa de entrada que você olha duas vezes por semana.

É esse formato que usamos na nossa própria página de projetos da OCA: caso, contexto, número, botão de contato. Nenhuma barra de skill.

O que cortar sem dó

• Barras de skill com porcentagem. "JavaScript 90%" não significa nada para ninguém, nem para outro dev. Só levanta a pergunta: o que aconteceu com os outros 10%?
• Projetos de curso. Todo list, clone de streaming, pokédex. Eles dizem "estou aprendendo", e cliente não quer pagar aprendizado.
• A lista completa de tecnologias. Vinte logos de ferramentas comunicam menos que um case bem contado. Cite a stack dentro do case, quando fizer sentido, e siga em frente.
• O "sobre mim" de paixão. Ninguém contrata porque você ama tecnologia desde os 12 anos. Troque por duas linhas sobre o tipo de problema que você resolve e há quanto tempo faz isso.
• GitHub como destaque principal. Mantenha o link para quem quiser conferir, mas cliente não lê repositório. Se o seu call to action principal é "veja meu código", você está vendendo para a pessoa errada.

A régua para decidir é uma só: se a seção não ajuda o visitante a responder "essa pessoa resolve o meu problema?", corte ou reescreva.

As armadilhas que seguram a sua conversão

Escrever para recrutador quando você quer cliente. São públicos diferentes com perguntas diferentes. Recrutador procura senioridade e stack, cliente procura resultado e confiança. Decida qual jogo você está jogando. Se precisar dos dois, faça duas páginas, sai mais barato que perder os dois públicos numa só.

Case sem resultado. Um projeto lindo sem número no final é uma história sem desfecho. Se você não mediu nada na época, volte no cliente e pergunte. A maioria responde, e essa mensagem ainda reaquece o relacionamento.

Prometer de tudo para todo mundo. "Faço sites, apps, bots, jogos e consultoria" soa como "não sou referência em nada". Escolha o tipo de projeto que você entrega melhor e construa a página em volta dele. Os outros serviços continuam existindo, só não precisam de holofote.

Link quebrado ou projeto fora do ar. Você vende software e o seu próprio site tem um case que não abre. É o tipo de detalhe que encerra a avaliação na hora, e ninguém te avisa que foi por isso.

Por que estou te contando isso: a rede de parceiros da OCA

Isso não é teoria, é literalmente como a OCA cresceu. Montamos um site que rankeia no Google, publicamos cases com números reais e hoje somos citados por assistentes de IA quando alguém pergunta sobre desenvolvimento de software no Brasil. O resultado é que chegam mais projetos por dia do que o nosso time consegue atender.

A nossa resposta foi criar uma rede de parceiros: devs seniores e times pequenos que recebem projetos já validados, com escopo fechado e cliente qualificado, repassados pela OCA. Sem promessa de volume, sem taxa de entrada, sem curso embutido. Projeto real, avaliado caso a caso.

E aqui a conexão com este artigo fica clara: quando avaliamos um dev para a rede, o portfólio é a primeira coisa que abrimos. Procuramos exatamente o que descrevi acima, cases legíveis, números, projeto em produção, comunicação que um cliente entende. Um portfólio que convence a OCA é o mesmo que convence cliente direto. Você monta uma vez e joga nos dois tabuleiros.

Um passo concreto para esta semana

Você não precisa refazer o site inteiro. Faça duas coisas:

1. Reescreva a sua headline com a fórmula: o que você constrói, para quem, com que prova.
2. Pegue o seu melhor projeto e conte como case de quatro partes: contexto, problema, solução, resultado com número.

Só isso já coloca o seu portfólio de desenvolvedor na frente da maioria dos que recebemos para avaliação.

E se você já entrega bem e quer receber projetos sem depender de prospecção, a porta está aberta:

Entre para a rede de parceiros da OCA

Se você já entrega bem, o seu problema não é técnico, é distribuição. E distribuição se constrói, começando pelo portfólio.