Portfólio de dev que gera cliente: o que colocar, o que cortar e o estudo de caso que fecha projeto (o modelo que a OCA usa em 2026)

Você tem projeto entregue. Tem cliente satisfeito, sistema rodando em produção, talvez um app publicado nas lojas. Aí alguém pede “manda seu portfólio” e você manda o link do GitHub, ou um site montado anos atrás com doze cards, uma barra de “React 90%” e a frase “dev apaixonado por tecnologia”. A pessoa agradece, diz que vai analisar e some.

O problema raramente é a sua competência. O portfólio foi feito para outro dev ler, e quem decide a contratação quase nunca é dev. É o dono de uma clínica, a sócia de uma imobiliária, o fundador que tem uma ideia e um orçamento apertado. Essa pessoa não abre o repositório. Ela passa uns 30 segundos na página tentando responder uma pergunta só: essa pessoa resolve o meu problema?

Se a sua página não responde isso em 30 segundos, ela não está trabalhando para você.

A verdade desconfortável: cliente não contrata stack, contrata resultado

Vou te falar como funciona do lado de quem recebe os leads: quase ninguém chega na OCA pedindo uma tecnologia. As mensagens dizem coisas como “preciso parar de controlar aluguel em planilha”, “quero vender ingresso sem pagar taxa de plataforma” ou “meu fornecedor sumiu e o app parou”. Next.js, React Native e Supabase só entram na conversa depois, e quase sempre porque a gente puxa o assunto.

Isso muda o que um portfólio precisa fazer. Ele não existe para provar que você sabe programar. Ele existe para traduzir código em consequência: o que mudou na vida do cliente depois que o sistema entrou no ar.

E tem um segundo ponto. Se você já entrega bem, o seu problema não é técnico, é distribuição. O tráfego (indicação, LinkedIn, Google, IA) leva a pessoa até você. O portfólio é a última milha: é ali que a visita vira conversa ou vira aba fechada. Dá para ter um bom SEO e perder todo lead na página de destino.

O que colocar no portfólio de dev: a estrutura que transforma visita em conversa

1. Uma headline que diz quem você atende e o que resolve

A fórmula que a gente usa é simples: o que você constrói + para quem + qual resultado + uma prova curta.

• Antes: “Desenvolvedor Full Stack | React | Node | TypeScript”
• Depois: “Construo sistemas web para imobiliárias que querem sair da planilha. Três operações rodando em produção.”
• Depois: “Apps em React Native para negócios de serviço, do protótipo à publicação nas lojas, com você falando direto com quem escreve o código.”

A versão “antes” serve para recrutador. A versão “depois” serve para quem paga o projeto. Se você ainda não tem um público definido, use o tipo de problema que mais resolveu até hoje. Não precisa ser perfeito, precisa ser específico.

2. Três a cinco estudos de caso, não vinte cards

Vinte projetos sem contexto parecem volume, mas obrigam o cliente a fazer o trabalho de entender o que cada um significa. Ele não vai fazer. Três estudos de caso bem escritos valem mais que uma grade inteira de screenshots. Escolha os projetos que mais se parecem com o trabalho que você quer receber, não necessariamente os maiores.

3. Um jeito óbvio de falar com você

Um botão de WhatsApp e um e-mail. Sem formulário de nove campos. E diga o que acontece depois do contato: “respondo em até um dia útil, a primeira conversa leva 20 minutos e não tem custo”. Isso tira o medo de quem nunca contratou dev e não sabe como funciona.

4. Quanto custa e quanto tempo leva

A conta é simples. Domínio .com.br no Registro.br sai por volta de R$ 40 por ano. Hospedagem estática em Vercel ou Netlify cabe no plano gratuito para um portfólio. Astro ou Next.js resolvem em poucas páginas. O custo real é tempo: um fim de semana para a primeira versão, de uma a duas semanas se você for escrever três estudos de caso com cuidado. O texto dá mais trabalho que o código, e é o texto que fecha projeto.

Anatomia do estudo de caso que fecha projeto

Cada estudo de caso segue a mesma ordem. O cliente lê de cima para baixo e para quando já tem a resposta, então o que importa vem primeiro.

1. Contexto do cliente. Que tipo de negócio, tamanho, momento. “Imobiliária com 400 contratos ativos controlados em planilha.”
2. O problema em linguagem de negócio. O que doía antes. Atraso, retrabalho, dinheiro perdido, cliente reclamando.
3. O que você decidiu e por quê. Inclusive o que você recomendou não construir. Isso mostra critério, que é exatamente o que o cliente não sabe avaliar sozinho.
4. Resultado mensurável. Usuários, horas economizadas, conversão, prazo cumprido, processos substituídos.
5. Seu papel exato. “Fiz sozinho o backend e o app” é diferente de “integrei um time de três e cuidei do frontend”. Seja preciso.
6. Stack, em uma linha. No final. Para o cliente é detalhe, para outro dev ou para uma software house é filtro.
7. Prova. Link do produto, screenshot, vídeo de 60 segundos navegando no sistema ou depoimento do cliente.

Quando a gente apresenta o Revo, não abre com React Native e Supabase. Abre com o que importa para quem lê: plataforma de descoberta e venda de ingressos com mais de 40 mil usuários cadastrados, mais de 300 eventos por mês e checkout próprio que converte 90%. A stack aparece depois, numa linha. Você pode ver esse formato aplicado nos projetos que a OCA tem em produção.

E se o projeto tem NDA ou não tem número?

Anonimize: “sistema de agendamento para uma rede de clínicas em São Paulo” já comunica muito sem expor ninguém. Se não existe métrica de negócio, use uma de operação: quantas planilhas o sistema substituiu, quantas pessoas usam todo dia, em quantas semanas foi entregue. E crie o hábito de pedir permissão e um depoimento curto no momento da entrega, quando o cliente está mais satisfeito. Depois de seis meses, ninguém responde esse e-mail.

O que cortar do portfólio de dev (e por que isso dói)

Cortar é a parte difícil, porque cada item ali custou horas suas. Mas tudo que não ajuda o cliente a decidir dilui o que ajuda.

Uma observação justa: clone de tutorial não é vergonha. Ele cumpre bem o papel quando você procura a primeira vaga e o leitor é um tech lead. Para cliente direto, ele só ocupa o espaço de um projeto que mostraria resultado.

As armadilhas que fazem o portfólio trabalhar contra você

• Mostrar o projeto que você não quer repetir. Portfólio atrai mais do mesmo. Se você odiou fazer e-commerce em WordPress e ele é o primeiro card, adivinha o próximo lead.
• Inflar o seu papel. Escrever “construí o app” quando você fez três telas parece inofensivo até a primeira call técnica. Quando a OCA avalia um parceiro, papel inflado é o sinal vermelho mais rápido de detectar e o mais difícil de esquecer.
• Expor dados de cliente. Screenshot com nome, CPF ou telefone real de usuário é problema de LGPD e de confiança. Use dados fictícios ou borre tudo.
• Página parada no tempo. Se o último projeto é de três anos atrás, o cliente conclui que você parou, mesmo que tenha entregado dez sistemas depois. Uma atualização por trimestre resolve.
• Preço baixo como argumento. “Orçamento mais barato da região” atrai exatamente quem vai pedir desconto depois. Se for falar de preço, fale de faixa e do que está incluído.

O que a OCA olha no seu portfólio antes de repassar um projeto

A OCA aparece no Google e nas IAs para buscas de desenvolvimento de software, e isso traz dezenas de leads por dia, mais do que o time consegue atender. Isso não é teoria, é literalmente como a OCA cresceu. Por isso estamos montando uma rede de parceiros: devs sênior e times pequenos que recebem projetos já qualificados e com escopo definido pela gente.

Quando um dev chega querendo entrar, o portfólio é a primeira coisa que a gente abre. O que pesa:

• Projetos em produção, com o seu papel descrito sem exagero.
• Clareza de escrita. O jeito que você explica um estudo de caso é o jeito que você vai mandar o update semanal para o cliente.
• Critério. Mostrar uma decisão que você tomou, e por quê, conta mais que mostrar uma tecnologia que você domina.
• Stack alinhada com o que mais aparece na demanda: React, React Native com Expo, Next.js, Node e Supabase.

O que o parceiro recebe: cliente já qualificado, escopo conversado antes de chegar até você e a OCA no meio da relação comercial. O que a gente não faz: prometer volume, prazo para o primeiro projeto ou aceite automático. A rede cresce conforme a demanda encaixa no perfil de cada parceiro, e a gente prefere ser honesto sobre isso desde a primeira conversa.

Entre para a rede de parceiros da OCA

O que fazer esta semana, entrando na rede ou não

1. Reescreva a headline do seu portfólio com a fórmula: o que você constrói, para quem, qual resultado e uma prova curta.
2. Escolha um projeto entregue e transforme em estudo de caso seguindo os sete blocos acima. Um só. Se der trabalho, é sinal de que você está escrevendo para o leitor certo.
3. Corte um item da tabela. Qualquer um.

São umas quatro horas de trabalho. Não garantem cliente, mas fazem a próxima visita chegar numa página que responde a pergunta que importa.