The landing page should inherit the app's restraint.

A squiggly arrow, five commits, zero days

On 2026-03-26 I built a hand-drawn “try me” arrow for the homepage. Squiggly, charming, pointing at a demo. It took five commits to get right. It was deleted the same day (commit 0c51729, 2026-03-26).

I keep that arrow in mind every time I touch the landing page, because it is what tightening looks like when you do not have a system: pure taste, applied commit by commit, in both directions, on the same afternoon. Five commits of effort producing zero commits of product. The fix for that is not better taste. It is machinery that makes restraint the default instead of a daily decision.

This post is about the homepage tightening pass I just shipped (commit 2ce7d46, 2026-06-07), but the pass only took an evening because the machinery already existed. That part took two months.

First, the tokens

The real work happened seven weeks before this post, on 2026-04-15, in a wave of ten commits (commit 9a3561d and c62b7dd, plus eight follow-ups the same day). The wave introduced container, spacing, and font-weight token scales, then went page by page stripping inline styles and hardcoded values. Every literal 1100px container width, every one-off 40px gap, replaced with a token.

The before state is the part worth being honest about. The site was a few weeks old and already had magic numbers scattered across every page. Not because anyone decided that, but because every page was styled in the moment it was built, and the moment always has its own opinion about spacing.

What tokens actually purchase is not consistency for its own sake. It is that “tighten the homepage” becomes a small diff. When section heights, gaps, and weights all derive from one scale, restraint is an edit to the scale, not an archaeology project across templates. The June pass touched the system files (home-page.ts, theme.css, typography.css) in the same commits that shipped that week’s launch posts (commits e461484 and b4f098f, 2026-06-06). Content and tightening in one push, because the tightening was that cheap.

Then, proof instead of decoration

The second piece of machinery landed 2026-05-27: a skill-file audit proof module on the home page (commit 16ab0fb, 2026-05-27), with the e2e assertions updated alongside it.

The pattern matters more than the specific module. Decorative sections answer “does this page feel impressive.” Proof modules answer “what does the product actually do, shown with current facts.” A release chain, an audit artifact, a real screenshot. Each one that replaces a decorative section makes the page harder to bloat, because proof has a maintenance contract: it has to stay true, and there are tests asserting it renders.

Decoration never carries tests. That is precisely why it accumulates.

What the June pass changed

With tokens and proof modules in place, the tightening itself (commit 2ce7d46, 2026-06-07) was mostly subtraction:

• reduced section heights, so the first scroll reaches product proof sooner
• flattened card shadows to match Studio’s flatter surfaces
• compact release facts instead of a tall release section
• one Inter/SF voice, mono reserved for commands and versions
• accent color held to focus states and the primary action
• nav trimmed to the pages that earn their slot

None of these is individually interesting, which is the point. The interesting version of this list is the one I would have written in March: new effects, new sections, a new arrow. Tightening that survives is boring line by line.

Restraint you can run

Update, June 8: the day after this post, the audit that closes the loop landed. A 209-line Playwright spec that checks the light theme against WCAG contrast requirements (commit dca0bf5, 2026-06-08).

This is the end state I was working toward. Restraint started as taste (delete the arrow), became tokens (stop hardcoding the numbers), became proof modules (sections must earn maintenance), and is now partially a test suite (contrast failures break the build). Each stage moves a judgment call out of my head and into the repo.

The honest framing of “the landing page should inherit the app’s restraint” is that inheritance has to be mechanical. The app’s discipline comes from its own gates and tests. If the site’s discipline lives in my mood, the two drift the moment I have a fun idea at midnight, and I have the five-commit arrow to prove it. The site stays restrained for the same reason the app does: because something fails if it is not.