Portfólio de desenvolvedor: o que colocar (e o que cortar)

Abri um portfólio de desenvolvedor semana passada e contei doze to-do apps. Doze. Todos com o mesmo layout do tutorial, a mesma paleta roxa, o mesmo botão de "Add task". O candidato achava que volume impressionava. O recrutador que olha isso por vinte segundos pensa o oposto: se são todos iguais, nenhum diz nada. Um portfólio não é um depósito de exercícios, é um argumento sobre o que você sabe fazer.

Este texto é sobre o que colocar nesse argumento, o que cortar sem dó, e por que um projeto terminado e no ar vale mais do que dez pela metade.

O recrutador te dá vinte segundos, no máximo

Antes de qualquer decisão sobre conteúdo, internalize a restrição real: ninguém vai estudar o seu portfólio. Um recruiter abre a aba, bate o olho, e decide em segundos se vale a pena rolar. Um tech lead que vai te entrevistar talvez gaste dois minutos antes da call. Esse é o orçamento de atenção que você tem.

Isso muda tudo. Significa que o valor precisa estar visível sem clique. Significa que a primeira dobra da página importa mais do que a sexta. E significa que enterrar o seu melhor projeto embaixo de três clones de tutorial e um jogo da velha é desperdício. Você não está sendo avaliado pela quantidade de coisas que já tocou; está sendo avaliado pela melhor coisa que conseguiu terminar e explicar.

Poucos projetos de verdade batem muitos pela metade

A opinião impopular: dois a quatro projetos substanciais derrotam dez repositórios meia-boca toda vez. Substancial não quer dizer enorme. Quer dizer que resolve um problema concreto, que você levou até o fim, e que tomou pelo menos uma decisão técnica não-óbvia no caminho.

Um projeto terminado, no ar e documentado comunica algo que dez projetos pela metade nunca conseguem: que você consegue fechar escopo. Fechar escopo é exatamente a habilidade que falta na maioria dos juniores e a que mais custa caro para o time. Quem mostra um produto pequeno mas inteiro está dizendo "eu termino o que começo". Quem mostra dez branches abandonadas está dizendo o contrário, mesmo sem perceber.

Sobre quais projetos de fato construir — qual problema escolher, como evitar o pântano do tutorial — eu cobri em detalhe em como projetos pessoais ajudam a conseguir emprego. Aqui o foco é o que fazer com os projetos depois que eles existem.

O link no ar vence o repositório

Se o projeto roda, coloque ele no ar. Um deploy público — Vercel, Netlify, Cloudflare Pages, Fly, qualquer um — muda a natureza do que você está mostrando. Um repositório é uma promessa: "confie que isso funciona". Um link ao vivo é uma prova: clica e usa.

A maioria dos recrutadores técnicos não vai clonar o seu repo, instalar dependências e subir um servidor local só para ver o seu CRUD funcionando. Eles vão clicar no link, ou não vão ver nada. Backend puro sem interface ainda merece deploy: suba a API, deixe um endpoint de exemplo respondendo, documente uma chamada com curl. A fricção entre "quero ver" e "estou vendo" precisa ser zero.

O README é a primeira impressão do projeto

Aqui mora o erro mais comum e mais barato de corrigir. Um projeto sem README decente é um projeto que ninguém entende — e um bom README é literalmente metade da impressão que o código causa. Se a pessoa abre o repo e vê uma parede de arquivos sem uma linha explicando o que aquilo é, o código perfeito por baixo não salva.

Um README que presta abre com o problema: o que isso resolve, para quem. Depois mostra como rodar em poucos passos. E então — a parte que separa junior de pleno aos olhos de quem lê — explica as decisões. Por que Postgres e não Mongo. Por que você não usou um framework de estado. O que você trocaria se tivesse mais tempo. Esses tradeoffs revelam que você pensa como engenheiro, não só digita como um. Se escrever do zero te trava, um gerador de README tira a página em branco do caminho e te deixa focar no conteúdo que importa.

Mostre decisão, não só código

Código qualquer LLM gera hoje. O que diferencia você é o raciocínio por trás dele. Por isso o portfólio mais forte não exibe arquivos — exibe escolhas. Uma seção curta de "como eu pensei" em cada projeto, ou um commit history limpo onde dá para acompanhar a evolução, vale mais do que mil linhas perfeitas sem contexto.

Cuidado com o commit history, aliás. Recruiter técnico abre a aba de commits. Uma sequência de "fix", "fix2", "asdf", "final final agora vai" conta uma história ruim. Não precisa ser conventional commits religioso, mas mensagens que descrevem o que mudou e por que sinalizam disciplina. E disciplina é contratável.

O que cortar sem dó

Tem coisa que envelhece o portfólio na hora. As barras de skill com porcentagem — "JavaScript 85%, Python 70%" — não significam nada e todo mundo sabe. Oitenta e cinco por cento medido contra o quê? Corte. O parágrafo "apaixonado por tecnologia desde os 12 anos" também não agrega; troque por uma frase concreta sobre o que você faz e onde quer chegar.

Links mortos são o pior de todos: um projeto "ao vivo" que dá 404 prova exatamente a incompetência que você quer esconder. Teste cada link antes de mandar o portfólio para qualquer vaga. Carrossel de logos de tecnologia sem contexto, certificados de curso de quarenta minutos, screenshots desfocados — tudo isso ocupa espaço que poderia estar trabalhando a seu favor.

Adapte ao cargo

Um portfólio não precisa ser estático nem único. Se você está aplicando para uma vaga de frontend, o projeto com a interface mais caprichada vai primeiro. Se é backend, lidere com a API bem modelada e o README que explica a arquitetura. Reordenar os projetos conforme a vaga leva cinco minutos e muda a primeira impressão inteira.

O mínimo viável de um portfólio: dois a quatro projetos de verdade, o GitHub com commits limpos, um "sobre" curto e honesto, uma forma clara de contato. Um blog técnico é bônus — mostra que você comunica — mas só se você realmente for mantê-lo. Blog com um post de 2023 é pior do que blog nenhum.

Perguntas frequentes

Quantos projetos devo ter no portfólio?

Dois a quatro projetos substanciais é o ponto certo. Acima disso você dilui a atenção e arrisca incluir trabalho fraco que puxa a média para baixo. Prefira profundidade: um projeto que você explica bem vale mais do que cinco que só existem.

Preciso ter os projetos no ar ou basta o GitHub?

Coloque no ar sempre que possível. O link ao vivo elimina a fricção e prova que funciona; o recrutador raramente vai clonar o repo. Para projetos de backend, suba a API com um endpoint de exemplo e documente uma chamada no README.

Vale a pena ter um blog no portfólio?

Vale se você for manter. Um blog ativo mostra que você comunica ideias técnicas, o que é raro e valioso. Mas um blog com um único post velho passa a impressão de projeto abandonado — nesse caso, melhor não ter.

Devo listar tecnologias que usei só uma vez?

Liste o que você consegue defender numa entrevista. Inflar a lista de stack com coisas que você tocou por uma tarde só cria expectativa que a conversa técnica vai desmascarar. Honestidade aqui te protege.

O que levar daqui

O portfólio não é um inventário do que você já viu; é um argumento sobre o que você entrega. Um projeto terminado, no ar e com um README que explica o problema e as decisões derruba dez clones de tutorial sem suar. Corte as barras de porcentagem, mate os links quebrados, limpe o commit history e deixe o valor óbvio nos primeiros vinte segundos. Quem lê tem pressa — facilite a vida dela e ela facilita a sua.