O que preparei antes de publicar meu primeiro site pessoal (kimura512.dev)
Conclusão
Ao publicar o kimura512.dev pela primeira vez, o maior consumidor de tempo não foi a implementação de código, mas transformar o site em algo que terceiros pudessem ler com confiança. Uma aplicação que só roda localmente sem operador identificado, sem canal de contato e sem política de privacidade é frágil como portfólio. Antes de abrir ao público, reuni Sobre, Privacidade, Contato e artigos fundamentais no mesmo marco de entrega.
1. Repositório e disciplina de compilação
Localmente as dependências são fixadas com pnpm; a esteira de produção roda pnpm run build seguido de wrangler deploy. Chaves de API residem unicamente nos Secrets do Cloudflare Workers e arquivos .env jamais entram no controle de versão. Para evitar incidentes, adotei uma regra clara: "Nenhum commit sobe para produção se falhar no build local". Rodar pnpm build antes de cada push identifica quebras de tipagem e rotas antes de atingir os usuários.
2. Checklist visual pré-lançamento
Antes de publicar, testo manualmente no navegador: se restam cards com "Em breve", se as rotas com prefixo de idioma não retornam 404, se as tags OGP de redes sociais funcionam e se o formulário de contato entrega mensagens reais. Manter essa lista documentada evita descuidos no momento do lançamento.
3. Linha de base do conteúdo
Apresentar apenas cards de projetos torna o site superficial. Elaborei artigos detalhados sobre decisões de arquitetura e superação de falhas para não inaugurar o espaço com textos vazios de boas-vindas. O filtro editorial foi simples: "Este texto realmente ajuda quem estiver diante do mesmo problema?" Ter conteúdo consistente desde o início transmite solidez profissional.
4. Validação de rede pós-deploy
Após a publicação, verifico se a listagem do blog, os artigos e as páginas de privacidade respondem com HTTP 200 no domínio principal. Embora o cadastro em ferramentas de busca possa ser feito depois, identificar marcações noindex indevidas é urgente. Inspecionar o código-fonte em abas anônimas contorna o cache local.
5. Unificação de domínio e e-mail
Todas as mensagens convergem para info@kimura512.dev, alinhando o formulário, a página Sobre e o rodapé. E-mails divergentes geram desconfiança. A cada atualização envio uma mensagem de teste para confirmar o recebimento ponta a ponta.
6. Coerência da navegação global
O rodapé disponibiliza links diretos para Blog, Sobre, Privacidade e Contato em todas as páginas. Projetos incompletos foram removidos da vitrine principal para que qualquer visitante compreenda o escopo do site sem barreiras.
7. Paridade entre ambiente local e produção
O hot-reloading do desenvolvimento local costuma ocultar particularidades de rotas em produção. Redirecionamentos de idiomas e envio de mensagens via endpoints de API nos Workers precisam ser validados após o build real.
8. Especialização entre vitrine e blog
A página inicial exibe projetos concluídos de forma concisa, enquanto o raciocínio técnico aprofundado pertence ao blog. Na primeira semana após a publicação, congelei novas funções para corrigir erros de digitação, verificar links quebrados e ajustar detalhes de políticas.
Resumo
Um primeiro lançamento não exige perfeição absoluta, mas capacidade de demonstrar transparência perante o público. Estruturar infraestrutura, diretrizes de privacidade e artigos sólidos no mesmo ciclo confere credibilidade de longo prazo.
Perguntas frequentes
Q. Qual o caminho mais rápido para um lançamento consistente?
Reunir Sobre, Privacidade, Contato, dois artigos aprofundados e a exclusão de itens incompletos em uma única entrega. Com essa base pronta, o site se mantém com tranquilidade.
Q. Quantos testes foram feitos antes de apontar o DNS?
Três deploys em Workers de preview e duas checagens completas após migrar o DNS para o domínio principal. Ambientes de teste evitam contratempos em produção.