Terminal Coffee Academy: como uma equipe de duas pessoas transformou uma ferramenta interna em um hub de conteúdo

Resumo Terminal Coffe Academy nasceu de uma necessidade simples: melhorar a produção das lives do Terminal Coffee. O projeto geral da marca começou com foco na prestação de serviços de desenvolvimento de software, mas a equipe decidiu expandir sua atuação para a produção de conteúdo técnico. Nesse contexto, surgiu o Academy, inicialmente pensado como uma ferramenta interna para exibir pautas de lives escritas em Markdown de maneira organizada. A ideia rapidamente evoluiu. Se o projeto já precisaria servir de infraestrutura para as pautas, por que não usá-lo também para centralizar os demais conteúdos produzidos pela equipe? O resultado foi um hub que reúne vídeos do YouTube, pautas, artigos, materiais educacionais e, futuramente, aulas e cursos. Tudo isso foi construído em 20 dias por uma equipe de apenas duas pessoas, sem orçamento dedicado e com tempo limitado para desenvolvimento. Em vez de adotar uma arquitetura convencional de aplicação web, a equipe escolheu o Eleventy e uma abordagem baseada em HTML, CSS, arquivos Markdown e arquivos estáticos. A decisão foi deliberadamente orientada pelos princípios: praticidade, flexibilidade, e custo mínimo. Mais do que um projeto de software, o Academy acabou se tornando também uma ferramenta de produção de conteúdo, um exercício de engenharia e uma vitrine das capacidades técnicas da própria equipe. O problema: as pautas existiam, mas não existia um processo O Terminal Coffee começou como um projeto voltado à prestação de serviços de desenvolvimento de software e, posteriormente, passou a investir também em conteúdo online. A equipe começou a produzir lives, aprender edição de vídeo, publicar no YouTube e experimentar diferentes formatos de conteúdo técnico. Um dos primeiros problemas percebidos estava justamente na preparação dessas lives. Cada transmissão precisava de uma pauta. Na prática, essas pautas eram pouco mais do que listas de links espalhadas por mensagens do WhatsApp, e canais do Discord O problema não era apenas estético. Não havia um processo formal para produção das pautas, era difícil recuperar materiais antigos, não existia uma apresentação adequada para ser usada durante a transmissão e os links usados durante a live não estavam organizados de maneira que também pudessem ser disponibilizados ao público. A equipe então definiu uma solução bastante simples: criar um site interno capaz de receber pautas escritas em Markdown e apresentá-las de forma estilizada. Essa primeira versão resolveria vários problemas de uma vez: - formalizar a produção das pautas; - criar uma tela de apoio para as lives; - manter todas as pautas versionadas em Git; - disponibilizar os links da transmissão publicamente. Foi justamente durante a discussão da implementação que surgiu uma nova possibilidade. Se o site já seria usado para publicar pautas, ele poderia também servir como ponto central para os outros conteúdos produzidos pelo Terminal Coffee. Foi assim que uma pequena ferramenta interna ganhou um escopo maior. De ferramenta interna a hub de conteúdo O produto deixou de ser apenas um visualizador de pautas e passou a funcionar como um hub para diferentes formatos de conteúdo. O escopo passou a incluir: - vídeos publicados no YouTube; - listagem e visualização de pautas; - uma interface específica para uso durante as lives; - artigos; - materiais educacionais; - futuras aulas e cursos; - links para as redes sociais da marca. A expansão, porém, não significou transformar o projeto em uma plataforma de gerenciamento de conteúdo completa. Essa distinção foi fundamental. A equipe era formada por apenas duas pessoas, ambas capazes de programar. Além disso, o objetivo principal do Terminal Coffee continuava sendo produzir conteúdo e, em paralelo, desenvolver outras atividades. O novo site precisava ajudar o trabalho, e não competir com ele. Esse requisito moldou todo o projeto. O princípio de engenharia: praticidade, flexibilidade, e custo mínimo Desde o início, a equipe adotou uma espécie de tríade de prioridades: praticidade, flexibilidade, e custo mínimo Não havia orçamento dedicado para o projeto. Também não havia justificativa para investir grandes quantidades de tempo em infraestrutura ou em funcionalidades que não contribuíssem diretamente para o objetivo. Isso eliminou, de imediato, algumas escolhas que seriam comuns em uma aplicação web tradicional. Não haveria um CMS completo. Não haveria banco de dados. Não haveria uma aplicação backend convencional. Não haveria React ou outro framework de frontend apenas porque ele era uma escolha popular. Em vez disso, a equipe escolheu o Eleventy, um gerador de sites estáticos. A escolha atendia exatamente às necessidades do projeto: templates, geração de páginas estáticas, conteúdo baseado em arquivos e uma stack pequena o suficiente para ser mantida por duas pessoas. A aplicação poderia ser essencialmente HTML e CSS, com apenas o JavaScript necessário. Essa simplicidade também reduzia o custo operacional. Como o resultado final era um conjunto de arquivos estáticos, o deploy poderia utilizar uma infraestrutura gratuita. No fim do projeto, a escolha foi pela Netlify. A arquitetura, portanto, não foi escolhida para atender ao maior sistema que o projeto poderia um dia se tornar. Ela foi escolhida para atender ao problema que existia naquele momento. Um projeto estático, mas não simplista O fato de ser um site estático não significava que o conteúdo fosse tratado de forma superficial. A estrutura do projeto foi organizada para acomodar diferentes tipos de material. Templates, componentes e layouts ficam em _includes , organizados em suas respectivas pastas. As páginas seguem uma estrutura convencional de HTML e CSS, com assets separados para estilos, scripts e imagens. As funcionalidades específicas do Eleventy aparecem principalmente na organização do conteúdo: - blog contém os artigos em Markdown; - learn reúne materiais educacionais, como presentations, lessons e courses. Escritos em páginas HTML customizadas a mão; - issues guarda as pautas das lives, também em Markdown; - _data concentra um JSON mantido manualmente com os vídeos publicados no YouTube. Essa estrutura permitiu acomodar formatos diferentes sem criar uma infraestrutura de conteúdo complexa. Um artigo pode ser um Markdown simples. Um material educacional pode ser uma página HTML personalizada. Uma pauta pode ser Markdown transformado em uma interface específica para apresentação. A própria plataforma não precisa hospedar os vídeos das futuras aulas. Seu papel é disponibilizar o material de apoio: textos, apresentações e outros recursos. Na prática, isso significa que a expansão da área educacional mantém a mesma lógica já usada no restante do projeto: adicionar conteúdo ao repositório e deixar o Eleventy fazer o trabalho de geração. O conteúdo virou parte do processo de engenharia Uma das características mais interessantes do Academy é que ele não foi desenvolvido isoladamente do restante da operação do Terminal Coffee. O software passou a fazer parte do próprio processo de produção de conteúdo. A página especial de pautas, por exemplo, deixou de ser apenas uma funcionalidade do site e passou a funcionar como uma ferramenta utilizada durante as gravações. A documentação do projeto também foi transformada em material para vídeos no YouTube. O desenvolvimento foi dividido em atualizações para a série chamada Project Brew. Decisões técnicas e descobertas do processo renderam conteúdo para redes sociais e LinkedIn. Isso criou um ciclo em que o produto ajudava a produzir conteúdo e, ao mesmo tempo, o desenvolvimento do produto gerava conteúdo. Para uma equipe pequena, esse efeito é particularmente importante: o projeto não precisava competir completamente com a produção de conteúdo porque parte do próprio esforço de desenvolvimento podia alimentar esse objetivo. Desenvolvimento em uma equipe de duas pessoas O Academy foi desenvolvido por Lucas e Eloy. Lucas atuou como engenheiro principal, responsável pela maior parte da programação e pelas principais decisões arquiteturais. Também participou como editor dos conteúdos e das gravações. Eloy assumiu principalmente o papel de Product Owner, além de cuidar da gravação, edição, produção para redes sociais e outras partes do conteúdo. Também contribuiu na programação de algumas páginas. Design e deploy foram decisões compartilhadas. Na prática, como acontece em muitas equipes muito pequenas, a divisão de responsabilidades não era rígida. Ambos faziam um pouco de tudo. As decisões eram tomadas por consenso. Uma ideia era discutida, seus trade-offs eram avaliados e, quando existia concordância, ela era implementada. O objetivo não era criar um processo corporativo artificialmente sofisticado. Era encontrar a maneira mais simples de coordenar duas pessoas. Git como infraestrutura de colaboração O mesmo princípio de simplicidade foi aplicado ao fluxo de desenvolvimento. O Git foi usado como mecanismo central de sincronização, tanto para código quanto para conteúdo. O fluxo é intencionalmente direto: - atualizar o repositório; - fazer as alterações; - adicionar e commitar; - fazer push. A equipe trabalha diretamente na branch principal, sem manter um ambiente de deploy separado. Isso pode parecer pouco convencional em comparação com processos de desenvolvimento mais sofisticados, mas foi uma decisão consciente. Com apenas duas pessoas, o maior risco seria criar complexidade de processo sem gerar benefício proporcional. Como os dois participantes se coordenavam previamente para reduzir conflitos, o trabalho direto na branch principal era suficiente. Os commits seguem uma adaptação de Conventional Commits. O Git também ajudou a transformar a produção de conteúdo em um processo mais disciplinado. Uma pauta não era mais apenas uma mensagem perdida no Discord: ela passava a ser um arquivo versionado dentro do próprio projeto. O pipeline de publicação O pipeline de deploy também segue a lógica de mínima complexidade. Depois que um