Bastidores da construção do brunopaim.tech

O brunopaim.tech começou como um espaço para organizar presença digital, mas virou também um laboratório de conteúdo, documentação, decisões técnicas e uso criterioso de IA.

Contexto

Quando comecei a organizar o brunopaim.tech, a ideia não era criar um site enorme.

O objetivo era ter um espaço próprio para centralizar links, estudos, projetos, blog e bastidores sobre desenvolvimento web, IA, automações, ferramentas digitais e produtos digitais. Um lugar que não dependesse só de redes sociais e que pudesse acompanhar minha evolução como desenvolvedor.

Mas, na prática, um site pessoal deixa de ser simples quando começa a carregar mais responsabilidade.

Ele precisa explicar quem eu sou, mostrar o que venho estudando, organizar conteúdos reaproveitáveis, preservar informações sensíveis, manter consistência visual e ainda funcionar bem tecnicamente. Não basta ter uma home bonita. O projeto precisa sustentar uma direção.

Foi aí que o site começou a virar também um laboratório de processo.

A construção passou por decisões de stack, organização de conteúdo, identidade visual, blog, SEO, imagens Open Graph, documentação AI First e um fluxo de specs antes de mudanças relevantes. Nada disso nasceu como uma metodologia fechada. Foi surgindo conforme o projeto pedia mais clareza.

Problema ou pergunta

A pergunta que me guiou em boa parte desse processo foi: um site pessoal precisa ser só uma vitrine?

No meu caso, a resposta foi não.

Eu não queria que o brunopaim.tech parecesse uma software house, uma página de venda ou uma promessa de serviço. Também não fazia sentido criar um portfólio cheio de métricas, cases ou informações que não deveriam estar ali.

O site precisava ter outro papel:

• organizar minha presença digital;
• registrar estudos e aprendizados práticos;
• centralizar projetos e links;
• apoiar a criação de conteúdo para blog, LinkedIn, Instagram e YouTube;
• mostrar evolução técnica sem inventar narrativa;
• funcionar como base segura para trabalhar com IA e agentes.

Isso muda a forma de construir.

Em vez de pensar só em layout, precisei pensar em posicionamento, tom de voz, limites, documentação e validação. O desafio não era apenas "como deixar bonito?". Era "como fazer o site continuar coerente quando ele crescer?".

Caminho testado

O caminho começou pela base técnica.

A stack atual usa Nuxt 3, Vue 3, TypeScript e Tailwind CSS. Essa combinação faz sentido para o momento do projeto porque permite manter uma aplicação estática, com rotas públicas, posts renderizados no HTML inicial, SEO por página, Open Graph e geração estática.

Antes disso, a base já tinha passado por uma primeira versão funcional em Vue, Vite, TypeScript e Tailwind. Essa versão ajudou a tirar o site do papel, organizar páginas principais e criar componentes reutilizáveis. Depois, a migração para Nuxt fez sentido porque o blog e as páginas públicas precisavam de uma base melhor para SEO e previews sociais.

Essa evolução técnica veio junto com uma decisão de escopo: não adicionar backend, banco de dados, CMS ou área administrativa nesta fase.

Pode parecer uma limitação, mas para o momento é uma vantagem. O conteúdo ainda cabe bem em arquivos locais, os posts seguem um fluxo editorial próprio e a complexidade fica sob controle. Antes de pensar em CMS, fazia mais sentido organizar o processo.

Outra frente importante foi a identidade visual.

O site usa uma estética dark, técnica e profissional, com verde como cor de destaque. A intenção não é criar um visual gamer, neon ou exagerado. A interface precisa parecer moderna, mas ainda acessível e sóbria. Isso vale para home, páginas internas, cards, blog, imagens editoriais e previews sociais.

O terceiro ponto foi a documentação.

O AGENTS.md, os documentos em docs/ e as specs em specs/ passaram a funcionar como memória do projeto. Eles registram o que o site é, o que ele não deve ser, quais informações são fixas, quais termos combinam com o posicionamento e quais mudanças exigem mais cuidado.

Essa documentação também ajuda no uso de IA.

Quando uma tarefa vem com contexto, restrições e critérios claros, a resposta tende a ficar mais útil. Quando o agente sabe que o site não deve vender serviços diretamente, não deve parecer software house, não deve inventar métricas e precisa preservar informações sensíveis, fica mais fácil manter o projeto alinhado.

Por isso, o fluxo de conteúdo também ganhou etapas:

1. ideia bruta;
2. pauta estratégica;
3. artigo em rascunho;
4. conteúdos reaproveitados;
5. aprovação manual;
6. implementação no site;
7. revisão final.

Esse processo não existe para deixar o blog burocrático. Ele existe para impedir que um texto solto vire publicação antes de ter tese, tom, contexto e validação.

Exemplo prático

Um exemplo simples é a própria criação dos posts do blog.

Antes de publicar um artigo, eu tento passar por uma pauta. A pauta define a tese principal, o público, o ângulo editorial, o que precisa entrar, o que fica fora de escopo, os links internos, a imagem Open Graph planejada e os possíveis reaproveitamentos.

Isso muda a conversa com a IA e muda a revisão humana depois.

Se eu peço apenas "escreva um post sobre meu site pessoal", a resposta pode ir para um caminho genérico. Pode parecer texto de agência, vender criação de sites, exagerar resultados ou inventar bastidores que não aconteceram.

Quando a pauta deixa claro que o foco é processo, aprendizado, documentação e decisões seguras do próprio projeto, o texto nasce em um espaço mais controlado.

O mesmo vale para mudanças técnicas.

Se a tarefa é mexer em um post, criar uma imagem OG ou alterar uma página pública, a documentação ajuda a lembrar que o site tem padrões: componentes reutilizáveis, dados estruturados em arquivos locais, cuidado com SEO, validação com build e geração estática quando aplicável, além de consistência entre português e inglês.

Esse é o ponto mais importante para mim: documentação boa não serve só para explicar o projeto depois. Ela melhora as decisões durante a construção.

Aprendizados

• Um site pessoal também precisa de posicionamento. Sem isso, é fácil cair em texto genérico, visual sem direção ou linguagem comercial demais.
• A stack importa, mas não resolve o projeto sozinha. Nuxt, Vue, TypeScript e Tailwind ajudam, mas o valor está no que a estrutura permite organizar.
• Conteúdo precisa de processo. Ideia, pauta, rascunho, aprovação e implementação são etapas diferentes.
• Documentação reduz ambiguidade. Ela ajuda a IA, mas também ajuda quem está revisando a resposta.
• Specs pequenas evitam mudanças maiores do que o necessário. Nem toda tarefa precisa de spec, mas mudanças relevantes ficam melhores quando têm objetivo, escopo e critérios.
• SEO não precisa ser artificial. Título, descrição, canonical, Open Graph e dados estruturados ajudam quando estão conectados ao conteúdo real.
• O blog pode ser uma base de aprendizado reaproveitável. Um post bem pensado pode virar resumo para LinkedIn, carrossel, roteiro curto e novos estudos.
• O projeto continua em evolução. A estrutura atual não precisa ser definitiva para ser útil agora.

Limites e ressalvas

Esse post não é um tutorial completo sobre como criar um site pessoal.

Também não é uma defesa de que todo projeto precisa começar com documentação extensa, specs e fluxo editorial detalhado. Em muitos casos, começar simples é o melhor caminho. O cuidado é perceber quando o projeto deixa de ser só uma tela e começa a virar uma base de conteúdo, aprendizado e presença digital.

Outro limite é que o brunopaim.tech ainda está em evolução. Algumas decisões podem mudar conforme o blog crescer, novas páginas fizerem sentido ou o fluxo de publicação exigir ajustes.

Por enquanto, faz sentido manter uma base estática, sem backend e sem CMS. Isso deixa o projeto mais simples, rastreável e fácil de validar. Se um dia essa estrutura limitar demais o conteúdo, aí sim a conversa muda.

Também vale reforçar: usar IA no processo não elimina revisão humana. A IA ajuda a organizar ideias, criar variações, revisar estrutura e acelerar partes do trabalho. Mas o critério sobre o que entra no site continua sendo meu.

Conclusão

Construir o brunopaim.tech tem sido menos sobre criar uma vitrine pronta e mais sobre organizar uma base que eu consiga evoluir com clareza.

O site reúne links, estudos, projetos, blog e bastidores, mas também registra um jeito de trabalhar: com documentação, escopo, revisão, cuidado editorial e uso criterioso de IA.

O principal aprendizado até aqui é que um projeto pessoal pode ser pequeno e ainda assim ter processo. Não precisa virar burocracia. Precisa apenas ter contexto suficiente para continuar coerente quando novas ideias, posts e mudanças começarem a aparecer.