Prova de trabalho precisa de versionamento
As páginas que carregam identidade e cases (home, English Tool, Leo, Pipeline Health) precisam de controle de versão e revisão antes de ir ao ar. São a prova do meu trabalho, não podem mudar por engano.
Arquitetura de produto · identidade de marca
Site Portfolio
O site que hospeda meus cases é, ele mesmo, um case: decisões de arquitetura, escopo de CMS e proteção de marca aplicadas ao meu próprio portfólio.
Contexto
Um portfólio precisa provar o mesmo rigor que mostra.
Eu precisava de um portfólio profissional que não fosse só uma lista de projetos: precisava provar, no próprio site, o mesmo rigor que mostro nos cases que ele hospeda. Isso significava decidir arquitetura, não só design: onde cada case vive, o que pode mudar sem deploy, o que precisa ficar protegido por versionamento, e como manter a identidade de marca consistente conforme o site cresce.
Percepção
Nem todo conteúdo deveria ser editável pelo mesmo caminho.
Um CMS mal escopado é risco de marca
Dar a um CMS acesso à página inteira significa que qualquer edição de conteúdo pode, sem querer, alterar algo já aprovado. A decisão foi limitar o CMS a uma área isolada e nunca deixá-lo tocar a camada de identidade.
Meu papel e processo
CMS escopado, cada case com sua própria rota.
Conduzi o desenvolvimento ponta a ponta (arquitetura, integrações, identidade aplicada em código), orquestrando ferramentas de IA para a implementação, com decisão final e validação em produto e marca.
Astro estático, deploy na Vercel
Performance e simplicidade, sem runtime de servidor desnecessário para um portfólio.
Storyblok só no blog
Integrado apenas ao content type blog_post, com o editor visual
desativado. Nenhum script é injetado nas páginas; a landing aprovada fica intocada
por decisão de arquitetura, não por limitação técnica.
Bug real contornado e documentado
getStaticPaths() do Astro roda antes do cliente oficial do Storyblok
ser inicializado pela integração, quebrando a listagem de posts. A solução foi usar
a biblioteca do cliente diretamente nessa camada, documentada no código.
Rascunho vs. publicado
Em desenvolvimento, mostro conteúdo em rascunho do CMS para revisar antes de publicar; no build de produção, só entra conteúdo com status "published".
Cada case mantém sua própria rota e dados. O Pipeline Health manteve
seu dashboard, filtros e endpoint de dados exatamente como estavam
(/crm), sem ser forçado a um template genérico de case, preservando a
análise e os números já validados.
Redirecionamentos de URLs antigas foram preservados via configuração da Vercel, para que links já compartilhados não quebrem com o redesign.
Documentação para mim mesma: escrevi um README em português simples explicando onde editar textos e cases sem precisar tocar em componentes — um contrato claro entre o que é conteúdo e o que é layout.
Entrega
O que está construído e em operação hoje.
- Site em produção em amandafranco.com.br, Astro + Vercel.
- Sistema de identidade aplicado de forma consistente: tipografia (Fraunces Variable + Space Grotesk Variable), paleta (papel, tinta, magenta, verde-limão) e ativos de marca em SVG vetorial.
- Três cases publicados com página própria: Pipeline Health (com dashboard interativo preservado), English Tool e Leo no WhatsApp.
- Blog integrado ao Storyblok, com fluxo seguro de rascunho e publicação.
- Redirecionamentos de URLs legadas configurados.
- README de manutenção para edição de conteúdo sem necessidade de código.
Status e replicabilidade
Em produção, com um padrão de arquitetura reaproveitável.
O site está em produção, com identidade aplicada e os três cases publicados e aprovados.
O padrão de arquitetura (conteúdo estático versionado para o que é prova de trabalho, CMS escopado e isolado para o que é editorial recorrente, com proteção de ambiente rascunho/publicado) é replicável para qualquer site que precise combinar páginas de marca protegidas com conteúdo editável sem comprometer consistência visual.