Skip to main content
Back to Featured
Website

n8builds.dev

This site, tested like a product

View sourceVisit live site
Next.jsPlaywrightOpen source
The n8builds.dev homepage hero at desktop width
Lighthouse report for the homepage from CI: performance 99, accessibility, best practices and SEO 100, LCP 0.9s, CLS 0
A GitHub Actions run: lint, types and unit tests, six E2E jobs and Lighthouse, all passing
The generated share card for this page

The problem

A personal site is usually the least-tested thing a developer ships: no tests, no performance budget, and a contact form any bot can flood. Visitors judge the work by it anyway, and the engineering behind it stays invisible.

The build

n8builds.dev holds my builds, the N8's Notions blog and the Loadout, and it is run like a product. Every pull request runs lint, type checks and more than 200 unit tests, then more than 450 Playwright tests across six browser projects in parallel (the APIs, plus Chromium, Firefox, WebKit, a Pixel 7 and an iPhone 14), then Lighthouse budgets on five pages. Branch protection holds every merge until it is green (a docs-only change skips the browser suite), and the source is public.

Stack & choices

  • Next.js 16 · React 19 · TypeScriptApp Router in strict mode; build pages are static, and blog posts revalidate hourly
  • Tailwind CSS 4 · MotionTheme tokens in CSS, scroll reveals, and reduced motion honored on every animation
  • SanityN8's Notions posts, read through the CDN client, so a new post needs no deploy
  • Vercel · CloudflareAuto-deploys from main and an edge rate limit on Vercel; DNS, email routing and Turnstile on Cloudflare
  • Upstash RedisContact-form rate limits shared by every serverless instance, failing closed when unreachable
  • SentryErrors and CSP violation reports, through a same-origin tunnel that forwards only this project
  • Playwright · VitestBrowser, accessibility (axe), security-header and API tests, plus unit tests, on every pull request
  • Lighthouse 13Three runs per page; CI fails if the median misses a performance, accessibility, FCP, LCP or CLS budget

Process notes

  1. 1

    The nightly Lighthouse run failed the homepage on layout shift (CLS 0.29). Slowing the CPU 6x reproduced it at 0.91: the browser painted the vertically centered hero before the page finished streaming in, and the hero re-centered as it grew. The hero is now top-aligned and its glows mount after hydration, and CLS measures 0.000 at 1x, 4x and 6x slowdown.

  2. 2

    Lighthouse budgets run in CI on the home, blog, build log, loadout and Solara pages on desktop, plus a mobile pass on the home, blog and builds pages. Recent desktop runs scored 0.98 to 1.00 for performance and 1.00 for accessibility, best practices and SEO; the homepage report pictured here has a 0.9s LCP and zero layout shift.

  3. 3

    An enforced Content-Security-Policy lists every third-party origin, next to X-Frame-Options, nosniff, a strict referrer policy, COOP and a Permissions-Policy that turns off the camera, microphone and location. An E2E test checks the headers on every page and fails on any CSP violation, including a full contact-form submission through Turnstile.

  4. 4

    The contact form checks size, content type, a Zod schema, a honeypot and a Turnstile token issued for this hostname, then allows 5 messages an hour per IP and a daily cap for the whole site. A Vercel WAF rule answers floods at the edge. In production, if Turnstile or Redis is unreachable, it rejects the message and asks the visitor to email instead.

  5. 5

    Every build page and blog post has its own 1200x630 share card, drawn with next/og over the same generated art as the blog covers. An API test walks the sitemap and checks each page for a canonical URL, a unique title and a preview image that loads.

  6. 6

    Built with Claude Code as the pair programmer: features are planned in docs in the repo, built in parallel git worktrees, and land as pull requests that branch protection holds until CI is green. This page was one of them.