We tell clients that their GTM stack should be a system: owned, testable, and stronger under stress. It would be embarrassing if our own website were a pile of duct tape. So we built it the way we build everything, and this post is the honest tour.
Content is data, not pages
Every glossary term, FAQ answer, essay, playbook, and case study on this site is a markdown file with zod-validated frontmatter. A build script compiles the whole content directory into a single JSON artifact. Listings, static params, the sitemap, and SEO tags all derive from that one source.
Adding a page means adding a file. There is no CMS to log into, no dashboard state to drift, no page builder that half the team is afraid to touch. Sixty glossary terms, forty FAQ pages, and twenty blog posts came from this pipeline, and the marginal cost of the next hundred is close to zero.
That is the same argument we make about CRM data: put the schema in code, validate at the boundary, and derive everything downstream from one clean source.
The design system is enforced, not suggested
Most style guides die because nothing stops you from violating them. Ours is a set of scripts that fail CI:
- Design check scans the codebase for off-palette colors, non-token font sizes, and rogue shadows. If a hex code is not one of ours, the build fails.
- Brand check enforces spelling of the brand name and holds a denylist of confidential client names, stored base64-encoded so the check itself never leaks what it protects.
- Local CI runs lint, both checks, types, tests, and a full production build in one command, mirrored exactly in GitHub Actions.
The palette is three colors: bone white, near-black, and a deep visceral red. Two typefaces: EB Garamond for headings, Courier Prime for anything that smells like data. Square corners, hard offset shadows, thick rules. The constraint is the style.
Screenshots are the test suite for design
Code tests catch logic bugs. Nothing in a unit test tells you that a section of your homepage renders as a blank cream band.
So we built a visual evidence tool: a script that boots the site, reads every route from the sitemap, and captures full-page screenshots at desktop and mobile widths into a contact sheet. Reviewing that sheet is how we caught our worst bug: the scroll-reveal animation system was leaving content invisible when the reveal trigger misfired. Whole sections of the page simply were not there.
The fix is a lesson in antifragile design. The animation now has four layers of defense: CSS only hides content after JavaScript confirms it is running, an IntersectionObserver reveals on approach, a scroll fallback sweeps anything already in view, and a slow polling loop catches environments where scroll events never fire at all. The failure mode is now "animation skipped," never "content missing." Decorative systems should degrade to boring, not to broken.
No vendor bets
The site is a static export deployed to edge hosting. No server to patch, no database to decay, nothing between the visitor and prebuilt HTML. The repo is a pnpm monorepo where SEO logic lives in its own package, so structured data and meta tags are typed functions, not copy-pasted strings.
If the host disappears tomorrow, the output directory deploys anywhere that serves files. That is tech-stack independence, practiced on ourselves.
What this has to do with your pipeline
Everything on this site follows the same four rules we apply to GTM systems:
- One validated source of truth. Content frontmatter with schemas, like a CRM with identity resolution.
- Checks that fail loudly in CI. Design and brand checks, like data accuracy floors.
- Evidence over vibes. Screenshot contact sheets, like signal engines with evidence chains.
- Degrade to boring, never to broken. Reveal fallbacks, like enrichment waterfalls.
A marketing site is a small GTM system. If a studio cannot engineer its own website this way, be suspicious of what it will do to your pipeline.