ADR-008 — Where the site lives
The landing page cannot pass the ADR-007 test, so it gets its own repository.
Date: 2026-09-03 · Status: accepted · Scope: repository, marketing, deployment
Context
The landing page is Next.js on Vercel with its own domain. The question was whether its code sits in the product repository or in one of its own.
ADR-007 already set the rule and the question to ask of any new file: could someone else reproduce or understand the product without it? A landing page fails that test — the CLI is entirely understandable and reproducible without a line of the site.
Scale matters too. Next.js with Tailwind and an animation library brings its own
package.json, its own lock file, its own CI, build configs and — most of all —
binary assets: a demo video, posters, og images. In a repository just cut from
491 files to 94 precisely so a clone would not carry someone else's weight, a
multi-megabyte mp4 is the same mistake in new packaging.
Options considered
| Option | For | Against |
|---|---|---|
A site/ folder in the product repo | Numbers and copy version alongside the product; one PR changes both | Breaks ADR-007; video in the product's git; the product diff drowns in marketing; needs Root Directory and Ignored Build Step on Vercel |
A separate kadence-site repository | The repository stays the product, as decided; a plain Vercel project; issues and stars do not mix with marketing | The numbers on the site can drift from the tests |
A gh-pages branch | No new repository | The worst of both: site history inside product history, and awkward to work in |
Decision
A separate repository. The product repository stays the product.
The argument that "the numbers come from the same tests" turned out weaker than it looked: in a shared repository they would still be copied by hand. So the cost is paid down with a mechanism instead of proximity:
- Every number on the site lives in one file,
content/facts.json, and each entry names the test or document that keeps it true. - The product's release checklist gains a line: update
facts.jsonif size, startup time or probe data changed. - When that starts being forgotten, a GitHub Action in the product publishes the benchmark as a release artefact and the site reads it at build time. Not worth building in advance while releases are rare.
Consequences
git cloneof the product still gives only the product; the site pulls whatever dependencies and assets it likes without asking ADR-007 for permission; Vercel deployment is standard.- Two repositories instead of one, and the numbers have to be synchronised deliberately.
- What would make us revisit it: if the site grows into documentation generated
from the code —
--helpoutput, the JSON schema — then the generator belongs in the product and the site consumes its output as a package or an artefact. Moving the site back is not the answer.