De ideia a 200 episódios: como o café com dopamina foi construído em paralelo com a carreira
Um site de conteúdo com 200+ episódios, 9 temporadas e 12 séries, construído nas margens do tempo de quem trabalha full-time. O que é a estrutura por baixo, as decisões que guiaram o projeto e o que ficou de aprendizado.
O café com dopamina existe há mais de uma década em alguma forma. Começou como anotações de aprendizado. Depois virou rascunhos. Depois virou tentativas de blog que ficavam no ar por alguns meses e sumiam. A versão atual — com sistema de temporadas, séries temáticas, navegação e deploy automático — é a primeira que sobreviveu ao teste do tempo.
Vale contar o que é diferente desta versão e o que aprendi no caminho.
A decisão fundacional foi tratar o conteúdo como produto, não como expressão. Produto tem estrutura, hierarquia, navegabilidade. Expressão tem liberdade, mas não tem sistema. A diferença prática: quando você tem um sistema claro — temporadas cronológicas por fase de carreira, séries temáticas cruzadas — cada episódio novo tem um lugar. Você não decide onde encaixa do zero toda vez. A estrutura carrega parte do trabalho editorial.
Isso parece pequeno até você ter 200 episódios. Com 200 episódios sem sistema, você tem uma pilha. Com sistema, você tem uma coleção. Coleção é navegável. Pilha não é.
A segunda decisão foi separar produção de publicação. Escrever um episódio é uma coisa. Publicar é outra. Com Deploy automático — PR criado pelo CI, merge manual feito por mim — o processo de publicação tem fricção mínima mas não zero. Essa fricção mínima é intencional: ela obriga uma revisão antes de publicar, mas não obriga um processo de produção que depende da publicação.
O resultado: eu consigo escrever vários episódios quando tenho energia criativa e estoque, e publicar gradualmente na cadência que faz sentido. O estoque absorve as semanas onde não escrevo nada.
O sistema técnico é simples por design. Markdown com frontmatter para os episódios. Next.js com export estático. GitHub Pages para hospedagem. GitHub Actions para build e deploy. Nenhum CMS externo, nenhum banco de dados de conteúdo, nenhuma dependência de plataforma terceira para o conteúdo em si. Os episódios são arquivos — portáveis, versionados, legíveis sem ferramenta especial.
Essa escolha tem um custo: funcionalidades dinâmicas são mais trabalhosas (comentários, busca full-text indexada, recomendações personalizadas). Mas tem um benefício que subestimei antes: a ausência de manutenção de plataforma. Não tem banco de dados para atualizar, não tem servidor para escalar, não tem plano de pagamento que pode mudar o preço. O conteúdo existe enquanto o GitHub existe.
O que quase matou o projeto três vezes foi o viés de complexidade. Em momentos diferentes ao longo dos anos, eu quase reescrevia tudo: para adicionar vídeo, para adicionar áudio, para migrar para uma plataforma mais "profissional". Cada vez que isso acontecia, o projeto parava — o custo de reescrever a plataforma consumia o tempo disponível, e o conteúdo ficava parado.
A lição que aprendi tarde: foque no que diferencia — o conteúdo — e resista ao impulso de melhorar o que suporta. A plataforma serve o conteúdo. Quando você passa a servir a plataforma, perdeu o foco.
A IA mudou a equação de formas específicas. A plataforma atual foi construída com agentes de código como colaboradores — o que eu levaria meses para implementar sozinho foi feito em semanas. Isso não mudou o que escrevo, mas mudou quanto tempo eu gasto gerenciando a plataforma versus escrevendo. O tempo ganho foi reinvestido em conteúdo.
Mas a IA não mudou o que é difícil: decidir o que escrever, encontrar o ângulo certo, escrever com voz própria. Esses continuam sendo os gargalos. E quando você remove o gargalo técnico, os gargalos de criação ficam mais visíveis — o que é bom, porque você passa a trabalhar no que realmente importa.
200 episódios não é uma conquista de um dia. É uma conquista de hábito — de escrever quando há energia, de não escrever quando não há, de não deixar a ausência de energia virar ausência de projeto. O projeto sobrevive ao longo prazo não pela disciplina de escrever todo dia, mas pela ausência de perfeccionismo que mata projetos: a disposição de publicar o suficientemente bom e continuar.
Essa semana: Se você tem um projeto de longo prazo que começou e parou várias vezes, identifique um padrão: o que provocou cada pausa? Foi falta de energia criativa, foi fricção técnica, foi viés de reescrever? Esse diagnóstico é o ponto de partida para uma versão do projeto que sobrevive ao longo prazo.