Case study · 2025–2026

pixelcompile.com

This site: a bilingual PT/EN presence on Next.js 15 and Cloudflare Pages, with its own design system, full security headers, observability and CI quality gates. The repository is itself a case study.

Context

I needed a presence of my own demonstrating the same engineering standard I offer clients - not a template with swapped colours. Bilingual (PT/EN), fast, and with full production practices from day one.

Problem

Presenting technical work and services credibly takes more than design: correct bilingual SEO (hreflang, per-locale metadata, structured data), security, observability and a deploy process that does not depend on manual discipline.

Constraints

Cloudflare Pages/Workers: every dynamic route must run on the Edge Runtime.
Next.js App Router requires unsafe-inline in the CSP - a documented trade-off, with a nonce-based approach planned.
Performance budget: LCP ≤ 2.5s, CLS ≤ 0.1, accessibility ≥ 95 (Lighthouse mobile).

Decisions

i18n as the routing backbone: next-intl with a mandatory locale prefix, detection via cookie → header → Accept-Language, and a CI gate that fails if pt.json and en.json diverge structurally.
A single middleware layering i18n routing and all security headers (HSTS, CSP, X-Frame-Options, Permissions-Policy).
A design system based on CSS tokens as the source of truth, exposed through Tailwind - a small, disciplined palette.
GitHub Flow with main as production: deploy = merge, with Cloudflare building from the repository itself.

Technical approach

Next.js 15 (App Router) with feature-first organisation, strict TypeScript and Zod validating both the environment and the contact form (honeypot + edge rate limiting). Observability with Sentry and cookieless analytics.

Quality in CI: i18n audit, unit tests with a coverage gate, Playwright E2E and Lighthouse CI.

Outcome

In production at pixelcompile.com since January 2026, bilingual with hreflang alternates, full security headers and continuous deployment. The repository - ADRs, tests, CI gates - doubles as a demonstration of the process I offer.

Mobile view of the site — fig. 02 - Mobile view of the responsive layout

Known limitations

The CSP uses unsafe-inline (an App Router requirement); the nonce-based version is planned.
The form rate limiter is in-memory on the edge - it resets on cold starts.

Learnings

Bilingual parity is not kept by discipline - it is kept by an automated gate that fails the build.
Treating my own site as a product (ADRs, performance budgets, observability) made it the best sales argument I have.