Caso de estudo · 2025–2026
pixelcompile.com
Este site: presença bilingue PT/EN em Next.js 15 sobre Cloudflare Pages, com design system próprio, headers de segurança completos, observabilidade e gates de qualidade em CI. O repositório é ele próprio um caso de estudo.
Contexto
Precisava de uma presença própria que demonstrasse o mesmo nível de engenharia que ofereço a clientes - não um template com as cores trocadas. Bilingue (PT/EN), rápida, e com as práticas de produção completas desde o primeiro dia.
Problema
Apresentar trabalho técnico e serviços de forma credível exige mais do que design: SEO bilingue correto (hreflang, metadata por locale, dados estruturados), segurança, observabilidade e um processo de deploy que não dependa de disciplina manual.
Restrições
- Cloudflare Pages/Workers: todas as rotas dinâmicas têm de correr em Edge Runtime.
- O App Router do Next.js exige unsafe-inline no CSP - um compromisso documentado, com abordagem por nonce planeada.
- Orçamento de performance: LCP ≤ 2.5s, CLS ≤ 0.1, acessibilidade ≥ 95 (Lighthouse mobile).
Decisões
- i18n como espinha dorsal do routing: next-intl com prefixo de locale obrigatório, deteção por cookie → header → Accept-Language, e um gate de CI que falha se pt.json e en.json divergirem estruturalmente.
- Middleware único a compor o routing i18n e todos os headers de segurança (HSTS, CSP, X-Frame-Options, Permissions-Policy).
- Design system baseado em tokens CSS como fonte da verdade, exposto ao Tailwind - paleta reduzida e disciplinada.
- GitHub Flow com main como produção: deploy = merge, com o Cloudflare a construir a partir do próprio repositório.
Abordagem técnica
Next.js 15 (App Router) com organização feature-first, TypeScript estrito e Zod na validação de ambiente e do formulário de contacto (honeypot + rate limiting no edge). Observabilidade com Sentry e analytics cookieless.
Qualidade em CI: auditoria i18n, testes unitários com gate de cobertura, E2E com Playwright e Lighthouse CI.
Resultado
Em produção em pixelcompile.com desde janeiro de 2026, bilingue com alternates hreflang, headers de segurança completos e deploy contínuo. O repositório - ADRs, testes, gates de CI - funciona como demonstração do processo que ofereço.
Limitações conhecidas
- O CSP usa unsafe-inline (exigência do App Router); a versão com nonce está planeada.
- O rate limiter do formulário é in-memory no edge - reinicia em cold starts.
Aprendizagens
- Paridade bilingue não se mantém por disciplina - mantém-se por um gate automático que falha o build.
- Tratar o próprio site como produto (ADRs, orçamentos de performance, observabilidade) tornou-o o melhor argumento comercial que tenho.