The work was real (features, fixes, infrastructure changes) but invisible. Clients saw results on their pages. Visitors saw a polished site. Nobody saw the pace. We wanted a way to make the cadence obvious without turning it into a marketing exercise.
The format we chose
Plain .txt files in a folder. That’s it. public/release-notes/ currently holds 33 files, one per week, dating from September 2025 to April 2026. Each file follows the same structure: an ASCII art header, sections marked with ==== Title ====, highlight bullets and a summary.
There’s no CMS behind it and no database — someone writes a .txt file, drops it in the folder, and it’s live on the next deploy. We publish every Thursday.
A CMS would mean logins, permissions, a content model to maintain. A .txt file means anyone on the team can write one in their editor and commit it.
633 lines of parser
The simplicity stops at the authoring surface. Underneath, a 633-line parser extracts the ASCII art, section headings, highlights, change counts and date labels from each file. It normalizes formatting, preserves casing like “ON Labs” and handles the edge cases plain text always produces.
Another 182 lines handle the interactive behavior: split panel on desktop, accordion on mobile, deep-linking so anyone can share a specific week’s notes. The total comes to 1,575 lines for what started as “just a folder of text files.”
The ASCII art
Every release has a unique ASCII art rendering of the ON logo at the top. Block characters, line art, Unicode blocks, dot patterns — 33 releases, 33 different treatments.
They serve no functional purpose, but they’re the first thing you see when you open a release. Scrolling through the archive, the variety makes each week feel distinct.
The footer trick
A small utility exposes the latest release date site-wide. The footer uses it to display when the site was last updated. It’s a single line of text, but it creates a site-wide signal: the site is actively maintained. A visitor on any page can see the last ship date without navigating to the release notes.
What kept the format going
Anyone can write a changelog. Most teams stop after a few weeks. The .txt format (no tooling required, no workflow to learn) is why ours kept going. The ASCII art gives people a reason to actually open them. Deep-linking means releases get shared in Slack threads and client emails as specific URLs. And the footer date quietly tells every visitor the site is alive.
Thirty-three Thursdays in a row, same format, same .txt files.
