Como montar seu portfólio de cases sem mentir

O portfólio que não converte

A maioria dos portfólios de dev parece catálogo de print screen. Screenshot do site, nome do cliente, link. Sem contexto, sem processo, sem resultado. O visitante vê 10 thumbnails bonitos e não sabe qual problema cada projeto resolveu.

Esse formato não diferencia você de mais ninguém. Todo dev tem screenshots. O que o cliente quer saber antes de contratar é: você já resolveu um problema parecido com o meu? Como resolveu? Qual foi o resultado?

Portfólio que converte não mostra o que você fez. Mostra o que você resolveu. A diferença parece sutil, mas muda tudo na hora de fechar contrato.

Case não é screenshot. É história.

Um case bem documentado responde quatro perguntas:

Qual era o problema? O cliente chegou com qual dor? Site lento, sem SEO, sem conversão, processo manual, sistema defasado. O problema é o gancho que conecta o visitante do portfólio com o case. Se ele tem a mesma dor, ele continua lendo.

O que você fez? Qual foi a solução técnica e estratégica? Stack usada, decisões de arquitetura, otimizações aplicadas. Não precisa ser tutorial. Precisa mostrar que você pensou no problema antes de sair codando.

Qual foi o resultado? Números. Lighthouse antes e depois. Tempo de carregamento. Posição no Google. Aumento de conversão. Redução de custo operacional. Resultado sem número é opinião. Resultado com número é prova.

O que o cliente achou? Depoimento real. Não precisa ser longo. Uma frase do cliente confirmando que o projeto resolveu o problema dele vale mais que 3 parágrafos seus explicando como você é bom.

No meu site, cada case segue essa estrutura. O Family Pilates mostra: problema (WordPress lento, Lighthouse 65), solução (migração pra Astro, SEO local), resultado (Lighthouse 98, LCP 0.8s). O AutoPars mostra: problema (marketplace de autopeças sem plataforma), solução (React + Supabase com 5 integrações), resultado (sistema completo com 3 painéis rodando em produção).

Números que importam (e números que não importam)

Nem todo número impressiona. “Site com 50 páginas” não diz nada sobre qualidade. “Lighthouse de 98” diz. Escolha métricas que o cliente entende e que demonstram valor real.

Métricas que funcionam:

• Lighthouse Score (antes vs depois)
• LCP / tempo de carregamento (segundos reais)
• Posição no Google pra keyword específica
• Custo de hospedagem (antes vs depois)
• Tempo de desenvolvimento (mostra eficiência)
• ROI quando mensurável (“site se pagou com X clientes”)

Métricas que não impressionam ninguém:

• “50+ componentes React” (cliente não sabe o que é componente)
• “10.000 linhas de código” (mais código não é melhor)
• “Stack moderna” (vago, não prova nada)
• “Design responsivo” (isso é obrigação, não diferencial)

No GPM2, o número que importa é Lighthouse 95+ com zero JavaScript no cliente. Pra um site de consultoria tributária, isso significa carregamento rápido e SEO técnico forte. O cliente não precisa saber que é Astro. Precisa saber que o site dele carrega em menos de 1 segundo.

No FitPlan, o número que importa é “redução de 37% em cancelamentos” após implementar notificação de inatividade. Esse número fala a língua do dono de academia. É mais convincente que qualquer detalhe técnico.

Como documentar quando o projeto é pequeno

“Mas meu projeto é só uma landing page, não tem case pra contar.” Tem sim. Toda LP tem problema, solução e resultado.

LP pra clínica odontológica:

• Problema: clínica investia R$ 3k/mês em Google Ads e recebia 2-3 contatos
• Solução: LP otimizada com CTA de WhatsApp, FAQ com objeções, Schema.org
• Resultado: 8-12 contatos/mês com mesmo investimento em ads

Isso é case. Não precisa ser marketplace com 5 integrações pra ter história. Precisa ter resultado mensurável.

Se você está começando e não tem clientes ainda, projetos pessoais contam. Mas apresente como case real: qual problema você quis resolver, como resolveu, e qual o resultado técnico (Lighthouse, performance, SEO). Projeto pessoal com Lighthouse 100 é melhor que projeto de cliente com Lighthouse 50. O que importa é a qualidade do trabalho, não quem pagou.

Página de cases: estrutura que funciona

A página de cases do portfólio precisa de duas coisas: visão geral rápida e profundidade sob demanda.

Visão geral (listagem). Card com: nome do projeto, categoria (LP, webapp, institucional), uma frase sobre o resultado principal, e thumbnail. O visitante escaneia 5-8 cases em 10 segundos e clica no que parece relevante pro problema dele.

Página individual do case. Aqui vem a história completa: problema, solução, resultado, depoimento. Com screenshots reais (não mockup genérico), métricas concretas, e link pro site em produção quando possível.

No meu site, a página de cases segue exatamente essa estrutura. Cards com resumo na listagem, página dedicada com detalhes pra cada projeto. O visitante que está pesquisando “dev pra site de clínica” vê o case do Family Pilates e entende em 30 segundos que eu já resolvi esse tipo de problema.

Evite jargão técnico na página de cases. O visitante pode ser o dono da empresa, não o CTO. “Migramos de WordPress pra Astro com SSG e deploy na Vercel via CI/CD” não comunica valor. “O site passou de 4 segundos pra 0.8 segundo de carregamento, e a hospedagem que custava R$ 100/mês agora é grátis” comunica.

O que não colocar no portfólio

Projetos que você não pode mostrar. Se o cliente pediu confidencialidade, respeite. Mencione o setor (“marketplace B2B no setor automotivo”) sem revelar nome ou dados sensíveis.

Projetos antigos que não representam seu nível atual. O site que você fez em 2019 com jQuery e Bootstrap pode ter sido bom na época, mas se tá no portfólio em 2026, o visitante acha que é seu nível atual. Mantenha só o que representa a qualidade que você entrega hoje.

Trabalho que não é seu. Parece óbvio, mas existe dev que coloca projeto de agência onde ele fez 10% do trabalho como se fosse projeto solo. Seja honesto sobre seu papel. “Fui responsável pelo frontend e integrações” é mais respeitável que fingir que fez tudo.

Quantidade excessiva. 5-8 cases bem documentados vendem mais que 30 thumbnails sem contexto. Qualidade mata quantidade em portfólio. Curadoria é parte do trabalho.

Como pedir depoimento sem ser constrangedor

Muitos devs não pedem depoimento porque acham invasivo. A verdade é que a maioria dos clientes satisfeitos não se importa de dar um depoimento. Eles só não pensam nisso espontaneamente.

O momento certo: logo depois da entrega, quando o cliente está satisfeito com o resultado. Mande uma mensagem simples: “Fico feliz que o projeto ficou como você queria. Se fizer sentido, um depoimento curto sobre a experiência me ajudaria muito. Pode ser por texto mesmo, 2-3 frases sobre o resultado.”

Se o cliente topar, direcione com perguntas: “Qual era o problema antes? Como tá agora?” Isso evita depoimentos genéricos tipo “Ótimo profissional, recomendo” e gera depoimentos com substância.

No Tok Final e no Soline, depoimentos dos clientes fazem parte da página do case. Não pedi nada elaborado. Pedi uma mensagem curta sobre o resultado. O cliente mandou por WhatsApp em 2 minutos.

Portfólio é ferramenta de vendas

Portfólio não é vitrine. É argumento de venda. Quando você entra numa conversa comercial e o lead pergunta “você já fez algo parecido?”, você manda o link do case específico. Não o portfólio inteiro. O case específico que mostra que você já resolveu o problema que ele tem.

No meu fluxo de prospecção pra clínicas de odontologia estética, quando o dentista pergunta sobre resultados, mando o link direto do case relevante. Não preciso explicar muito. O case fala por mim: problema, solução, resultado, número.

Portfólio bem feito vende sem você precisar vender. É a prova silenciosa de que você sabe o que faz.

• Cada case tem problema, solução e resultado documentados?
• Os resultados têm números concretos (Lighthouse, tempo, ROI)?
• A linguagem é acessível pra não-técnicos?
• Tem depoimento real de pelo menos 3 clientes?
• A página de cases tem visão geral (cards) e profundidade (página individual)?
• Os cases representam seu nível atual de trabalho?
• Você remove projetos antigos que não representam mais sua qualidade?

O melhor marketing que um dev pode fazer é mostrar trabalho real com resultado real. Sem exagero, sem mentira, sem screenshot bonito sem contexto. Um case bem documentado vende por você enquanto você tá codando o próximo projeto.