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:
-
blogcontém os artigos em Markdown; -
learnreúne materiais educacionais, como presentations, lessons e courses. Escritos em páginas HTML customizadas a mão; -
issuesguarda as pautas das lives, também em Markdown; -
_dataconcentra 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 conteúdo é aprovado, ele entra no repositório. O commit feito por Eloy é o gatilho para o deploy.
A Netlify detecta a alteração, executa o build do projeto usando Eleventy e publica automaticamente a nova versão.
A equipe não precisou desenvolver uma infraestrutura própria de CI/CD.
Mais uma vez, a escolha foi abrir mão de controle e sofisticação desnecessários para ganhar velocidade e reduzir o custo operacional.
O papel da inteligência artificial no design
A inteligência artificial teve participação significativa no processo de design, mas não como substituta da equipe.
A primeira etapa foi definir os design tokens. A equipe partiu de uma extração simples das cores presentes na identidade visual do projeto e utilizou IA para refinar essa base.
Depois, o processo de prototipação passou pelo Arena AI.
A primeira rodada teve um objetivo exploratório: apresentar o conceito de maneira aberta, gerar diferentes possibilidades e observar quais propostas realmente combinavam com o gosto da equipe.
Esse momento foi importante porque a equipe percebeu que não precisava começar o processo sabendo exatamente qual design queria. Podia explorar alternativas e descobrir suas próprias preferências durante o caminho.
A segunda rodada foi mais controlada. A equipe utilizou uma especificação mais robusta para a homepage e, a partir dela, gerou o protótipo que serviu de base para o layout final.
A ideia não era aceitar o resultado da IA como produto acabado.
Era usá-la como instrumento de exploração.
De React + Tailwind para HTML + CSS
Os protótipos iniciais gerados pelas IAs utilizavam React e Tailwind.
O produto final, porém, não precisava dessa complexidade.
A equipe então converteu o resultado para HTML e CSS utilizando ITCSS e CUBE CSS, incorporando recursos modernos da própria plataforma web, como cascade layers e view transitions.
Esse processo serviu também como uma etapa importante de refinamento.
Boa parte do resultado gerado pela IA precisava ser revista. Nomes de classes foram melhorados, elementos genéricos foram substituídos pelas tags semânticas apropriadas e atributos de acessibilidade foram adicionados.
A equipe percebeu uma diferença importante entre geração e engenharia:
A IA conseguia produzir uma primeira versão muito rapidamente, mas não tinha como substituir o julgamento necessário para decidir o que realmente deveria permanecer.
Alguns elementos do design eram visualmente interessantes, mas não contribuíam para a experiência. Outros continham textos que pareciam adequados visualmente, mas não faziam sentido naquele contexto.
Foram necessários ajustes relativamente pequenos — remover conteúdo desnecessário, revisar textos, incluir botões e adaptar componentes — mas suficientes para mostrar que o resultado da IA precisava passar por uma camada humana de direção e refinamento.
Um exemplo curioso disso foi justamente o design de botões: os protótipos não resolveram esse componente de maneira satisfatória, e posteriormente a equipe precisou pensar e implementar essa parte manualmente.
IA como acelerador, não como motor
A principal conclusão da equipe sobre inteligência artificial foi direta: vibe coding não compensa.
O código inicial podia ser produzido muito rapidamente, mas o resultado exigia refatoração significativa para atingir os padrões de qualidade esperados.
Isso não tornou a IA inútil. Pelo contrário.
Ela se mostrou extremamente útil para tarefas repetitivas e de groundwork:
- gerar descrições para os cards das pautas;
- sugerir títulos;
- explorar ideias por diferentes ângulos;
- produzir uma primeira versão de páginas;
- apoiar tarefas mecânicas durante a implementação.
O ganho mais interessante, porém, não veio de aumentar o volume de funcionalidades entregues.
A equipe manteve aproximadamente o mesmo tempo médio de desenvolvimento que teria sem IA, mas utilizou o tempo economizado na etapa inicial para melhorar a qualidade do resultado final.
Em vez de usar produtividade adicional para produzir mais coisas “boas o suficiente”, a equipe usou a IA para acelerar o trabalho manual e, depois, investir o tempo equivalente no refinamento.
O resultado foi uma troca importante:
menos tempo gasto fazendo o sistema funcionar e mais tempo disponível para fazer o sistema ficar bom.
O “Brew”: quando exploração gera produto
Durante a fase exploratória de design, apareceu um pequeno elemento que não fazia parte dos requisitos iniciais.
Em um dos protótipos surgiu a ideia de um widget interativo chamado Brew: um copo de café que vai sendo preenchido conforme o usuário pressiona um botão.
A funcionalidade era, essencialmente, um easter egg.
Mas ela representava algo maior no projeto.
Durante a exploração visual, a equipe percebeu que queria que o site tivesse personalidade, e não apenas aparência funcional.
O Brew acabou sendo uma consequência direta desse processo exploratório e se tornou uma pequena assinatura da identidade da plataforma.
É um bom exemplo de como a exploração assistida por IA não serviu apenas para gerar layouts, mas também para revelar preferências que a equipe ainda não havia explicitamente formulado.
O que mudou na prática
O Academy já está em produção e quase completamente utilizável, embora ainda receba alguns ajustes finais.
O ganho mais visível apareceu justamente no problema que deu origem ao projeto.
Durante uma live, a equipe deixou de depender de uma tela vazia enquanto preparava a transmissão. A pauta passou a funcionar como uma tela de apoio e como guia para conduzir a apresentação.
Isso eliminou interrupções que antes aconteciam quando era necessário, por exemplo, parar para anunciar que seria aberto o Discord em busca de um link.
Agora, a equipe simplesmente segue a pauta.
O Git também melhorou a organização interna. O conteúdo passou a ficar centralizado em um lugar acessível a todos, com histórico e versionamento.
E o próprio site trouxe um benefício estratégico: tornou-se uma vitrine das capacidades atuais do Terminal Coffee, preenchendo uma lacuna que existia no portfólio.
Resultados além do software
Os resultados não ficaram limitados à organização interna.
A equipe relata que vem conquistando maior constância no YouTube e que a média de visualizações subiu de aproximadamente 15 para cerca de 30 por vídeo.
Os conteúdos específicos relacionados ao Project Brew também vêm apresentando uma recepção positiva em comparação com a média do canal.
Embora esses números ainda sejam pequenos em termos absolutos, eles mostram que o próprio desenvolvimento do produto conseguiu gerar conteúdo com valor para a audiência.
O projeto também mostrou que era possível integrar diferentes formatos de conteúdo de maneira muito mais simples do que a equipe inicialmente poderia imaginar.
Essa facilidade de integração acabou sendo uma das surpresas positivas do projeto.
O que a equipe decidiu não construir
Parte do sucesso do Academy veio justamente das coisas que ele não faz.
A equipe deliberadamente evitou recursos que exigiriam a introdução de backend e persistência tradicional quando esses recursos não eram necessários.
Um exemplo é o envio de e-mails.
Em uma aplicação convencional, seria natural adicionar esse tipo de funcionalidade. No Academy, o custo arquitetural de introduzir backend não justificava o benefício naquele estágio.
O mesmo raciocínio foi aplicado ao fluxo de deploy, ao modelo de branches, à hospedagem e ao gerenciamento de conteúdo.
A equipe aceitou soluções manuais quando elas eram suficientemente eficientes.
O JSON do YouTube é atualizado manualmente quando um vídeo é publicado.
Isso não é necessariamente uma solução mais elegante do que uma integração automatizada com a API do YouTube. Mas evita introduzir uma dependência e uma camada de complexidade que, naquele momento, não traziam valor suficiente.
Essa é uma constante do projeto:
a solução tecnicamente mais sofisticada nem sempre era a solução mais adequada.
O que permanece aberto para o futuro
A equipe não trata o Eleventy como uma decisão irreversível.
Caso o Academy se transforme futuramente em uma plataforma robusta, a intenção seria preservar principalmente a estrutura conceitual dos conteúdos, mas substituir a infraestrutura.
O Eleventy provavelmente daria lugar a um backend de verdade, e a persistência atualmente distribuída em arquivos seria consolidada em um banco de dados com garantias de consistência e normalização.
Isso não é visto como uma falha da arquitetura atual.
É simplesmente uma consequência de ela ter sido otimizada para a fase em que o projeto está hoje.
O objetivo inicial nunca foi construir a plataforma definitiva. Foi construir a menor ferramenta capaz de resolver o problema real.
Lições
1. Uma equipe pequena precisa otimizar o projeto pelo custo total
Quando o software não é diretamente a fonte de receita, seu maior perigo é consumir o tempo necessário para o trabalho que realmente importa.
O projeto precisa justificar seu próprio custo.
No caso do Academy, isso significou aceitar uma arquitetura menos sofisticada em troca de velocidade, simplicidade e baixo custo operacional.
2. “Profissional” não significa necessariamente “mais complexo”
Branchs, ambientes separados, pipelines personalizados, backend e banco de dados podem ser boas práticas em muitos contextos.
Mas práticas não existem isoladamente dos requisitos.
Em um projeto mantido por duas pessoas, algumas dessas decisões poderiam representar mais trabalho de coordenação do que valor efetivo.
O processo escolhido foi “não profissional” apenas se a definição de profissionalismo for baseada em complexidade.
Do ponto de vista dos requisitos, ele era adequado.
3. Conteúdo e software podem formar um ciclo
O Academy não foi apenas uma ferramenta usada pelo processo de conteúdo.
Ele também passou a ser uma fonte de conteúdo.
A documentação virou vídeo. As decisões viraram posts. A evolução do software virou uma série.
Para uma equipe pequena, esse tipo de sinergia pode ser mais valioso do que simplesmente aumentar a quantidade de features.
4. IA acelera o processo, mas não substitui engenharia
A experiência da equipe reforçou uma posição clara.
A IA é excelente para exploração, geração de groundwork e tarefas repetitivas.
Ela também pode reduzir drasticamente o tempo necessário para chegar à primeira versão.
Mas a responsabilidade pela qualidade continua sendo humana.
O valor não está em aceitar o primeiro resultado gerado. Está em chegar mais rápido ao ponto em que a equipe pode começar a exercer seu julgamento sobre ele.
5. Simplicidade é uma decisão arquitetural
O maior aprendizado do projeto talvez seja também o mais simples.
Quando questionada sobre a principal filosofia de engenharia do Academy, a equipe volta sempre aos mesmos três critérios:
simplicidade, flexibilidade, e custo mínimo.
Esses critérios orientaram a escolha do Eleventy, a ausência de backend, o uso de hospedagem gratuita, a manutenção manual de determinados dados, o fluxo de Git e até a forma como a inteligência artificial foi incorporada ao processo.
Conclusão
O Terminal Coffee Academy começou como uma resposta para um problema pequeno: organizar as pautas utilizadas nas lives.
Seu desenvolvimento poderia facilmente ter seguido o caminho tradicional de transformar essa necessidade em uma aplicação cada vez mais sofisticada.
A equipe escolheu fazer o contrário.
Em vez de construir uma plataforma antes de saber se precisava dela, construiu uma ferramenta simples capaz de resolver os problemas atuais.
Em vez de criar um CMS, usou arquivos.
Em vez de adicionar backend, usou geração estática.
Em vez de montar uma infraestrutura própria, utilizou a infraestrutura oferecida pela hospedagem.
Em vez de usar IA para substituir o desenvolvimento, usou IA para acelerar as partes mecânicas e preservar mais tempo para o trabalho intelectual.
E, em vez de tratar o desenvolvimento como uma atividade separada da produção de conteúdo, transformou o próprio processo em conteúdo.
O resultado é um projeto que representa bem uma realidade comum — e frequentemente ignorada — de equipes pequenas: a melhor arquitetura não é necessariamente a mais poderosa, mas a que resolve o problema certo sem atrapalhar o resto do trabalho.
No caso do Terminal Coffee Academy, essa arquitetura ainda pode mudar no futuro.
Mas, enquanto o objetivo for continuar produzindo conteúdo, aprendendo e evoluindo a marca, a escolha continua pagando seu custo.
E esse talvez seja o maior indicador de que a engenharia está funcionando.
Ass. Equipe do Terminal Coffee.
Top comments (0)