Como fazer um site de portfólio para desenvolvedor (que gera vaga e freela, não só estrela no GitHub)

O erro número um do portfólio de dev brasileiro: cada projeto é um card com nome, print e uma fileira de badges de tecnologia. React, Node, PostgreSQL, Docker. Isso descreve a ferramenta, não o trabalho. É como um pedreiro anunciar "uso furadeira Bosch e nível a laser" sem mostrar uma obra pronta.

Cada projeto no seu site precisa contar uma micro-história em três linhas:

• O problema: o que existia antes? "Loja fazia pedido por planilha e perdia venda no fim de semana."
• O que você construiu: aqui sim entra a stack, em uma frase. "Fiz um sistema de pedidos em Next.js com painel admin e notificação por WhatsApp."
• O resultado: o que mudou. "Está em produção desde março, processando os pedidos da loja sem planilha." Se tiver número real, use. Se não tiver, "está no ar e sendo usado" já vale mais que nada — projeto em produção é raridade em portfólio júnior.

Repare que o resultado não precisa ser "escalei pra 1 milhão de usuários". "Virou produção" já é resultado. "Cliente usa todo dia" é resultado. "Automatizou 2 horas de trabalho manual por semana" é resultado. O que não é resultado: "projeto feito para praticar React". Isso diz ao recrutador que ele está olhando exercício, não trabalho.

E se todos os seus projetos são de estudo? Escolha um e transforme em real: pegue um problema de alguém próximo (a lanchonete do bairro, o consultório da sua dentista, o grupo da igreja) e resolva de verdade. Um projeto usado por uma pessoa real vale mais no portfólio que cinco clones de Netflix.

O GitHub é o depósito de ferramentas; o portfólio é a vitrine. Quem se interessa pela vitrine talvez visite o depósito — e aí ele precisa estar apresentável, porque dev técnico avaliando você (tech lead, CTO de startup) vai clicar sim.

Checklist de 30 minutos pra deixar o GitHub pronto pra receber visita:

• Fixe 4 a 6 repositórios (pinned) — os mesmos que estão no portfólio. Nada de deixar o algoritmo de ordenação da faculdade em primeiro.
• README com print e uma frase de contexto em cada repositório fixado. Não precisa ser documentação completa: imagem do projeto rodando + o problema que resolve + como rodar. Três seções.
• Apague ou torne privado o lixo: forks abandonados, "teste-api-2", repositório vazio. Menos é mais.
• Foto e bio preenchidas, com link de volta pro seu site. O GitHub deve apontar pro portfólio, e o portfólio pro GitHub — os dois se reforçam.

No site, o link do GitHub entra em dois lugares: no cabeçalho/rodapé (perfil geral) e dentro de cada projeto ("ver código"). Mas atenção: o botão principal de cada projeto é o link do projeto no ar, quando existir. Ver a coisa funcionando convence qualquer pessoa; ver código convence só quem é dev.

Três projetos fortes batem dez medianos, sempre. Portfólio não é inventário — é curadoria. Quem coloca tudo que já fez obriga o visitante a garimpar, e ele não vai garimpar.

Critério de corte, do mais forte pro mais fraco:

• Projeto real em produção (cliente, freela, projeto próprio com usuários) — entra sempre, em primeiro.
• Projeto próprio completo que resolve um problema seu de verdade — entra.
• Projeto de estudo com algo único — entra se você mudou algo substancial em relação ao tutorial de origem. Se é o clone idêntico que outros 5 mil devs fizeram no mesmo curso, corta.
• To-do list, calculadora, landing page de curso — corta. Recrutador que vê 200 portfólios por mês reconhece esses de longe, e eles jogam contra: sinalizam que você só fez o mínimo guiado.

Se depois do corte sobraram só dois projetos, tudo bem — publique com dois e trate isso como lista de tarefas: seu próximo projeto já nasce sabendo que vai pro portfólio, o que muda como você o escolhe. Prefira algo pequeno e terminado a algo ambicioso e 60% pronto. Projeto pela metade não entra no site. "Em breve" em portfólio é vaga perdida.

Ordem na página: o mais impressionante primeiro, sem ordem cronológica. Ninguém se importa com a linha do tempo; importa o melhor tiro logo na primeira dobra.

A maioria das páginas "sobre mim" de dev segue o mesmo molde: "Sou fulano, apaixonado por tecnologia desde criança, atualmente estudando X e buscando oportunidades". Isso não diferencia você de ninguém — é literalmente o que todos escrevem.

A página sobre que funciona responde o que o visitante quer saber, na ordem que ele quer saber:

• O que você faz, em uma frase concreta. "Desenvolvo sistemas web pra pequenos negócios: painel de pedidos, agendamento, integração com WhatsApp." Melhor que "desenvolvedor full-stack apaixonado por criar soluções".
• Pra quem / em que contexto. Trabalha melhor com produto? Com agência? Com negócio local que precisa de sistema? Dizer pra quem você serve filtra os contatos certos.
• Trajetória em 2-3 frases com fatos, não adjetivos. "Comecei automatizando planilhas na empresa onde trabalhava, migrei pra desenvolvimento web em 2023, hoje mantenho dois sistemas em produção." Trajetória de transição de carreira, aliás, é ponto a favor quando bem contada — mostra que você resolve problema no mundo real, não só no exercício.
• Uma foto sua. Rosto gera confiança, principalmente pra cliente de freela que vai te mandar Pix sem nunca ter te visto. Não precisa ser ensaio profissional; precisa ser nítida e recente.

O que cortar: lista de soft skills ("proativo, comunicativo"), a história da infância com o computador do primo, e qualquer frase que sirva pra qualquer dev do Brasil. Teste prático: se um colega pode colar o mesmo parágrafo no site dele sem mudar nada, o parágrafo não diz nada sobre você.

Portfólio sem caminho claro de contato é panfleto sem telefone. E aqui o contexto brasileiro manda: botão de WhatsApp é obrigatório. Cliente de freela — dono de loja, dentista, corretor — não vai preencher formulário nem escrever e-mail formal; ele quer mandar "oi, vi seu site, quanto custa um sistema de agendamento?" e receber resposta no mesmo dia.

Estrutura de contato que converte:

• WhatsApp com link direto (wa.me) e mensagem pré-preenchida tipo "Olá! Vi seu portfólio e queria conversar sobre um projeto". Reduz a fricção de quem trava na primeira frase.
• E-mail visível pra recrutador e empresa — RH costuma preferir e-mail e LinkedIn ao WhatsApp no primeiro contato.
• LinkedIn atualizado e linkado, com o site no destaque do perfil.
• Chamada específica, não genérica: "Precisa de um sistema pro seu negócio? Me chama no WhatsApp que te respondo hoje" funciona; "entre em contato" não diz nem pra quem nem pra quê.

Sobre o primeiro cliente: ele quase nunca vem do Google — vem da sua rede. O portfólio entra como prova, não como canal de aquisição. O fluxo que vejo funcionar: você comenta que faz sites e sistemas, alguém conhece alguém que precisa, essa pessoa pede "me mostra algo que você fez" — e aí, em vez de mandar link de GitHub que ela não vai entender, você manda um link limpo com projetos, resultados e seu WhatsApp no final. Divulgue o link na bio do Instagram, no status do WhatsApp e em grupos de indicação da sua cidade. Pra fechar: combine escopo por escrito (mesmo que seja mensagem no próprio WhatsApp), peça um sinal via Pix antes de começar e entregue algo visível na primeira semana. Cliente pequeno confia em quem mostra progresso cedo.

Versão em inglês do portfólio é opcional — e a resposta certa depende do seu alvo nos próximos 12 meses.

• Vale a pena se: você quer vaga remota internacional, freela em plataforma gringa (Upwork, Contra, Toptal) ou empresa brasileira com time global. Nesses casos, a versão em inglês não é luxo, é requisito de entrada — recrutador de fora fecha a aba no primeiro parágrafo em português.
• Não vale (ainda) se: seu foco é vaga local, freela pra negócio da sua cidade ou primeira posição júnior no Brasil. Nesse cenário, um portfólio em inglês pode até atrapalhar o cliente pequeno, que abre a página e não entende nada.

Se for fazer, faça direito: traduza também a descrição dos projetos e os READMEs dos repositórios fixados, não só o menu. Portfólio em inglês apontando pra README em português quebra a experiência exatamente pra quem você queria impressionar. E evite tradução automática crua na página sobre — é o texto onde o inglês capenga mais aparece. Peça revisão pra alguém fluente ou simplifique as frases até ter certeza delas.

Um caminho intermediário que resolve pra maioria: site em português com os títulos dos projetos e nomes de tecnologia já em inglês (que é como o mercado fala mesmo) e um PDF de currículo em inglês linkado. Quando a oportunidade internacional aparecer de verdade, você monta a versão completa em um fim de semana.

Ironia clássica: dev passa três meses escolhendo framework pro próprio portfólio, começa do zero duas vezes, e o site nunca sai do localhost. Enquanto isso, as vagas e os freelas continuam passando. O portfólio é ferramenta de trabalho, não prova de conceito — ele precisa estar no ar, não perfeito.

Você tem dois caminhos honestos:

• Construir do zero — válido se o próprio site for uma peça do portfólio (você é front-end e quer mostrar animação, performance, design). Nesse caso, trate como projeto com deadline: uma semana, escopo fechado, publica e itera.
• Usar um modelo pronto e gastar sua energia no conteúdo — que, como vimos, é o que realmente decide contratação. O Tavoren tem um modelo de site para desenvolvedor (modelo pronto) com seções de projetos, stack, trajetória e contato já estruturadas do jeito descrito neste guia: você preenche com seus projetos e resultados, conecta GitHub e WhatsApp, e o site fica pronto sem você brigar com deploy nem CSS de madrugada.

Checklist final antes de divulgar o link:

• Abre rápido no celular? (Recrutador e cliente vão abrir do celular.)
• O melhor projeto aparece sem rolar muito?
• Cada projeto tem problema, solução e resultado — não só stack?
• WhatsApp e e-mail funcionam? (Teste os links de verdade.)
• GitHub fixado e com READMEs nos projetos linkados?

Se marcou os cinco, publica. Dá pra montar seu site grátis hoje e ajustar os textos ao longo da semana — portfólio no ar recebendo visita sempre vence portfólio perfeito no localhost.