Portfólio de dev que gera lead: o que colocar, o que cortar e por que o seu não converte cliente

Você tem um portfólio. Tem link no GitHub, uma lista de projetos, talvez um site com seu nome no domínio. E mesmo assim o cliente não chega por ali. Quando chega algum projeto, é por indicação ou por plataforma, nunca porque alguém abriu sua página, entendeu o que você faz e chamou. Se isso descreve sua situação, o problema não é a qualidade do seu trabalho. É que seu portfólio foi escrito para impressionar outro dev, e outro dev não te contrata.

Vou te falar como funciona do lado de quem recebe os leads: na OCA, dezenas de pessoas chegam todo dia procurando quem construa software. Nenhuma delas pergunta sobre arquitetura hexagonal. Todas perguntam alguma variação de "você resolve o meu problema, quanto custa e quando fica pronto". O portfólio que converte é o que responde isso em trinta segundos.

A verdade desconfortável: seu portfólio fala com a pessoa errada

A maioria dos portfólios de dev é uma lista de tecnologias e repositórios. "Fullstack | React | Node | TypeScript | AWS". Isso funciona para processo seletivo, porque o recrutador técnico filtra por stack. Cliente não filtra por stack. Cliente não sabe o que é stack.

O dono de uma imobiliária que precisa de um sistema de gestão não digita "desenvolvedor Node.js" no Google. Ele digita "sistema para imobiliária" ou pergunta para o ChatGPT quem faz isso. Quando ele cair na sua página, ele precisa se reconhecer nela. Se a primeira coisa que ele vê é uma lista de siglas, ele fecha a aba e vai para o próximo.

Isso não é teoria, é literalmente como a OCA cresceu. Nossa página de projetos não abre com tecnologia. Abre com o que cada produto faz e para quem: plataforma de eventos com mais de 40 mil usuários, agente de voz com IA para pesquisas por telefone, sistema de gestão para imobiliárias em produção. A stack aparece depois, como detalhe, para quem quiser conferir.

O que colocar no portfólio: a anatomia de um case que vende

Esqueça "projetos". Pense em "cases". A diferença é que projeto descreve o que você construiu e case descreve o que o cliente ganhou. Cada case precisa de quatro blocos, nesta ordem:

1. O problema em uma frase. "A operação da empresa rodava em planilha e WhatsApp, e os pedidos começaram a se perder." Quem tem o mesmo problema se reconhece na hora.
2. O que foi entregue, em linguagem de negócio. "Um sistema web onde a equipe registra pedidos, acompanha status e o dono vê o faturamento do dia." Nada de "API RESTful com autenticação JWT".
3. Um número. Usuários ativos, pedidos processados, horas economizadas por semana, tempo de resposta que caiu. No Revo, nosso produto próprio, o número que a gente usa é o checkout com 90% de conversão. Um número real vale mais que três parágrafos de adjetivo.
4. A stack, no fim, em uma linha. Ela existe para dar credibilidade técnica a quem sabe avaliar, não para abrir a conversa.

Se você não pode citar o nome do cliente por confidencialidade, descreva o segmento: "distribuidora de médio porte no interior de SP". Funciona quase igual. O que não funciona é case sem contexto nenhum, tipo um print de dashboard sem explicação.

Quantos cases? Menos do que você acha

Três cases bons batem dez medianos. O visitante não vai ler dez. Escolha os três que têm o melhor número, o problema mais reconhecível ou o segmento onde você quer mais clientes. Os outros podem existir numa página secundária, mas a home mostra só o filé.

O que cortar sem dó

• Projetos de curso e clones de tutorial. Clone do Netflix, todo list, pokédex. Para o cliente, isso comunica "nunca atendi ninguém de verdade". Se você só tem projeto de estudo, construa uma coisa real: um sistema para o comércio de um conhecido, uma ferramenta que você mesmo usa. Um projeto real pequeno vale mais que cinco clones.
• A lista gigante de tecnologias. Vinte logos de ferramenta dizem "eu faço de tudo", e quem faz de tudo não é especialista em nada. Corte para o núcleo do que você entrega bem.
• Bio em terceira pessoa cheia de adjetivo. "Profissional apaixonado por tecnologia e inovação" não diz nada. Troque por uma frase de posicionamento: "Construo sistemas web para empresas que cresceram além da planilha".
• GitHub como destino principal. GitHub é anexo, não vitrine. Cliente não lê código. Linke, mas não mande ninguém para lá como primeira parada.
• Preço escondido demais ou exposto demais. Tabela de preço fixa te trava, mas zero sinalização assusta. Uma frase resolve: "Projetos a partir de R$ X" ou "orçamento em até 48h após a primeira conversa".

A estrutura da página que converte visita em conversa

A conta é simples: o visitante decide em segundos se continua ou fecha. A ordem da página importa tanto quanto o conteúdo.

1. Headline de posicionamento. Quem você atende e o que entrega. Fórmula que funciona: "[o que você constrói] para [quem] que [problema]". Exemplo: "Aplicativos e sistemas para empresas que perderam o controle da operação no WhatsApp".
2. Prova imediata. Um número ou um logo logo abaixo da headline. "Mais de 15 sistemas em produção" ou o case mais forte resumido em uma linha.
3. Os três cases, no formato de quatro blocos acima.
4. Como você trabalha. Três ou quatro passos: conversa inicial, proposta com escopo fechado, entregas quinzenais, suporte pós-entrega. Isso mata a maior objeção do cliente, que é o medo de contratar dev e o projeto sumir. Quem já foi queimado por um freela que desapareceu lê essa seção com lupa.
5. Um único CTA, repetido. Botão de WhatsApp com mensagem pré-preenchida. Não dê cinco opções de contato. Formulário longo mata conversão; a gente testou os dois e o WhatsApp ganha fácil no Brasil.

O teste dos trinta segundos

Mande sua página para alguém não técnico, um amigo, um parente que tem comércio. Peça para a pessoa olhar por trinta segundos e responder: o que esse cara faz, para quem, e o que eu faço se quiser contratar? Se ela travar em qualquer uma das três, a página não está pronta. Esse teste custa zero e vale mais que qualquer auditoria de design.

As armadilhas que mantêm seu portfólio invisível

Perfeccionismo de dev. Você adia publicar porque quer refazer o site na stack nova, com animação, dark mode e Lighthouse 100. O cliente não vê nada disso. Uma página simples no ar hoje gera mais lead que a página perfeita que nunca sai do localhost.

Portfólio sem canal de tráfego. Página boa sem visita é outdoor no deserto. O portfólio é o destino; você ainda precisa de um caminho até ele: conteúdo que rankeia no Google, perfil ativo no LinkedIn, presença nas respostas das IAs. É a mesma máquina que a OCA montou, e ela é replicável, mas é outra conversa. O portfólio vem primeiro porque é para onde todo canal aponta.

Atualizar nunca. Case de 2021 como projeto mais recente levanta a pergunta errada: "o que ele fez nos últimos anos?". Reserve uma hora por trimestre para atualizar. É manutenção, igual dependência de projeto.

O que a OCA olha no portfólio de um parceiro

Aqui vai a parte que me interessa diretamente. A OCA recebe mais demanda do que consegue atender, e por isso repassamos projetos escopados para uma rede de devs e times seniores parceiros. Antes de repassar qualquer coisa, a gente olha o portfólio do parceiro, e olha exatamente o que descrevi acima: cases reais com contexto, sinal de que a pessoa já atendeu cliente de verdade, comunicação que um leigo entende. Não precisa ser bonito. Precisa ser claro.

Um portfólio confuso não te desqualifica tecnicamente, mas nos diz que o cliente final vai ter dificuldade de se comunicar com você, e projeto repassado só funciona quando o parceiro segura a relação sozinho. Se você entrega bem e quer receber projetos já vendidos e escopados, o caminho é esse: Entre para a rede de parceiros da OCA. Manda junto o link do seu portfólio, mesmo que ele ainda esteja no formato antigo. A gente responde com sinceridade sobre o que ajustar.

Uma ação para esta semana

Independente da rede, faça isto até sexta: reescreva a headline do seu portfólio com a fórmula "[o que você constrói] para [quem] que [problema]" e transforme seu melhor projeto em um case de quatro blocos, com problema, entrega, número e stack. Duas horas de trabalho. Se você já entrega bem, o seu problema não é técnico, é distribuição, e distribuição começa por uma página que qualquer cliente entende em trinta segundos.