New We sign every review. Reviewer never equals author.

Published 2026-10-06

How we work

Not a portfolio of client outcomes -- a look at the roles, the approval process and six real pull requests from building and running this site itself.

Roles and approvals

Architect plans. Engineer builds. QA tests in a real browser and merges. SEO verifies on the live site. The reviewer is never the author.

Approvals are risk-tiered: routine changes ship on automated checks alone, while changes touching security, data or production access wait for a person.

Six pull requests

Six pull requests from building and running this site, one accurate fact each:

  • PR #17 -- Added the company's LinkedIn profile URL to the Organization schema's sameAs array; verified live on pna.agency.
  • PR #18 -- Added the SECURITY_HEADERS data file (src/data/security-headers.ts) that holds only the editable header values; the ALLOWED_SECURITY_HEADERS allowlist and the withSecurityHeaders() filter that enforce it stay in the protected worker/index.ts, not the data file.
  • PR #20 -- Gave each page in the sitemap its own lastmod value -- the latest commit touching that page or any shared layout/component/data/style file it depends on -- instead of one build-time date for the whole site.
  • PR #28 -- QA caught a card-hover contrast regression (text had dropped to 4.24:1); this PR fixed the --bg-card-hover token to reach 4.88:1.
  • PR #29 -- Hardened scripts/check-contrast.mjs to check that card-hover pair automatically, so the same regression cannot pass the build again.
  • PR #32 -- Added security.txt at /.well-known/security.txt with a contact address, expiry date and canonical URL, giving security researchers a standard disclosure channel.

Current state

This site is an operating, self-maintaining system: it ships its own changes through the same reviewed pipeline described above, on itself.

What this does not prove

This is our own site, not client work. It shows process, not business outcomes.