PostTrainLLM had a bright editorial website and a dark application. Both were coherent on their own, but the transition between them felt like leaving one product and entering another.
The repair was mostly structural. Shared color variables moved the public pages, documentation, artifact pages, and application toward the same dark research-lab palette. Teal became the live signal across surfaces. The loss-curve mark became the common visual anchor.
This was a useful reminder about design tokens. They are easy to dismiss when a product has only a handful of pages. Their value appears when the product grows and the visual language needs to change without editing every surface independently.
The redesign also kept the claims inspectable. Report cards and limitations still sit beside the visual polish. A stronger identity would have been a regression if it made uncertain results look more conclusive.
The complete build log is at https://posttrainllm.com/devlog.
Top comments (1)
The line about regression is the sharpest thing here, and it's the one part your token system can't carry forward.
Shared variables move teal and the loss-curve mark onto every new surface automatically. The restraint you just described, keeping report cards and limitations next to the polish so uncertain results stay uncertain, moves nowhere. It lived in your judgement for the length of this redesign.
Which is fine while you build every surface yourself. It stops being fine the moment someone else adds a page, or an agent generates one from the same tokens. They inherit the palette and none of the caution, so the output ends up looking more finished than the results underneath it. That is the exact regression you avoided by hand.
The version of this I'd write down isn't a token but a sentence: when a claim is uncertain, the visual treatment stays plainer than the confident case. Boring rule, and the only part of your reasoning a variable file has no slot for.