Portfólio de desenvolvedor que gera cliente

Portfólio que gera cliente responde a uma pergunta só: "esse profissional já resolveu um problema parecido com o meu?". Lista de tecnologias, grade de logos e vinte repositórios não respondem isso. Três estudos de caso curtos, com problema, decisão e resultado, respondem, e são o que separa portfólio decorativo de portfólio comercial.

O que quem contrata realmente olha

Existem dois públicos, e eles querem coisas diferentes:

• Recrutador ou tech lead (vaga): quer código, consistência de commits, testes, organização. GitHub ajuda muito aqui.
• Dono de empresa ou gestor (projeto): quer saber se o sistema vai funcionar, quanto tempo leva, se você some no meio e se já fez algo do gênero. Esse público não abre seu repositório.

Se seu objetivo é fechar projeto, escreva para o segundo. Ele decide por confiança e por reconhecimento do próprio problema, não por qualidade de código, que ele não consegue avaliar.

A estrutura de estudo de caso que funciona

Cada projeto merece uma página com esta sequência:

1. Título com o resultado ou o problema. "Sistema de agendamento que eliminou 20 horas semanais de retrabalho" funciona melhor que "Projeto Clínica X".
2. Contexto em duas linhas. Setor, porte, o que a empresa fazia antes.
3. O problema, em linguagem de negócio. Planilha que travava, dados duplicados, pedido perdido, retrabalho, cliente reclamando.
4. O que foi feito. Módulos, integrações, o que ficou de fora e por quê.
5. Decisões técnicas relevantes, e a razão. Uma ou duas. "Optamos por X em vez de Y porque o cliente precisava de Z." É aqui que sua competência aparece de verdade.
6. Resultado. Números quando existirem, descrição honesta quando não. Nunca invente métrica.
7. Stack, no final e discreta. Ela é qualificação, não argumento de venda.

Duas a quatro capturas de tela, com dados fictícios se necessário. Se houver sigilo, descreva sem identificar.

O que cortar

Um portfólio enxuto comunica critério. Portfólio que mostra tudo comunica que você não sabe o que é importante.

Quando você não tem projeto real para mostrar

Todo mundo começa aqui. Três alternativas que funcionam melhor que clone de rede social:

• Resolva um problema de um negócio que você conhece. A padaria do bairro, a clínica onde você é paciente, o time de futebol amador. Sistema pequeno, problema real, história contável.
• Trabalho voluntário para uma ONG ou associação. Vira estudo de caso legítimo e frequentemente gera indicação.
• Ferramenta pública que resolve algo específico do seu nicho. Um calculador, um conversor, um painel com dados abertos. Mostra iniciativa e serve de isca.

O que importa é a estrutura da narrativa: problema real, decisão consciente, resultado verificável. Um projeto pessoal bem contado supera cinco tarefas de curso.

Prova social e sinais de confiança

Confiança se constrói com pequenos sinais espalhados pela página:

• Depoimento curto de cliente, com nome e empresa quando permitido. Peça logo após uma entrega bem-sucedida, é quando a pessoa está mais disposta.
• Tempo de mercado e quantidade de projetos, se for favorável.
• Como você trabalha: ciclo de entregas, frequência de comunicação, o que acontece após o lançamento. Isso reduz o medo do cliente de ser abandonado.
• Localização e alcance. Empresas gostam de saber onde você está. A Retti Tech, por exemplo, deixa claro que é do Brasil e atende clientes no Brasil e em Portugal, informação simples que responde uma dúvida silenciosa.

O que o portfólio precisa ter tecnicamente

Ele é a primeira amostra do seu trabalho. Falhas aqui pesam:

• Carregamento rápido e boa nota em métricas básicas de performance.
• Funciona no celular. A maioria dos acessos vem de lá.
• Contato visível em todas as páginas, com um canal só de preferência (WhatsApp ou formulário curto).
• Endereços legíveis: /projetos/sistema-agendamento-clinicas em vez de /p?id=17.
• Títulos e descrições próprios em cada página, para quem chega por busca.

Um chamado à ação que não afasta

"Entre em contato" pede um compromisso vago. Prefira algo concreto e de baixo risco: "me conte seu problema em 20 minutos e eu digo se dá para resolver e quanto custa mais ou menos".

Isso funciona porque nomeia o formato, a duração e o que a pessoa leva embora. E deixa evidente que a conversa é sobre o problema dela, que é o único assunto que faz alguém contratar um desenvolvedor.