← Back to journal
May 28, 2026·3 min read·Building TarmacLabs

One feed for four products

Trim had its own changelog. AutoBrief had a CHANGELOG.md. TarmacLabs.org was tracking its own commits in journal posts. Tonight I consolidated them into one feed at /changelog. Here's why.

By David Sawires
Share

Until tonight, TarmacLabs had three different changelogs in three different places, none of them talking to each other.

Trim's lived at cfitrim.com/changelog — Phase 1 through 15, real release dates, written for CFIs. AutoBrief's lived in a CHANGELOG.mdfile inside the repo, never rendered on the web. Tarmaclabs.org's lived in a string of journal posts where you had to infer the release from the prose.

Three different audiences, three different formats, zero cross-reference between them. A chief pilot reading the AutoBrief CHANGELOG would never see that the engine running AutoBrief shares its rules pattern with Trim's endorsement audit. A freelance CFI reading Trim's changelog would have no idea TarmacLabs ships free tools they can use. Investors looking at any one of these would only see a third of the company.

The fix is just naming

The actual content was already correct — every release in every product has a date, a summary, a phase. The problem was geography. Tonight I moved everything to tarmaclabs.org/changelog, color-coded by product (Trim blue, AutoBrief indigo, TarmacLabs orange, Tools green), with filter chips for the readers who only want to follow one product.

Three changelogs is what a company that's actually three companies looks like. One changelog is what a company looks like.

Why the parent site, not the product sites

The instinct is to keep each product's changelog on each product's domain. cfitrim.com/changelog feels right for a CFI tool. autobrief.app/changelog will feel right for a dispatch tool. Each lives where its users already are.

But TarmacLabs as a company has a story that bigger than either product alone. The shared engine architecture — the same kind of pure-function rules engine runs Trim's endorsement audit AND AutoBrief's GO/NO-GO check. The shared brand decisions — orange Tarmac mark, status-chip color taxonomy, "flight deck never cockpit". The shared infrastructure — same Vercel team, same Supabase Pro upgrade decision blocking both products, same Resend API key handling auth emails.

Putting the changelog on the parent site lets an investor or a curious developer or a future hire see the WHOLE shape of the company on one URL. Trim shipped Phase 15 security a week ago; AutoBrief shipped V1 live today; Tools added a W&B calculator the same evening. Those are connected — they're the same person shipping with the same engineering values, just across different surfaces.

What stays on each product site

Cross-links. From the Trim changelog page, eventually, a link to "the rest of the company's shipping log" → here. From AutoBrief's landing, a link to "everything TarmacLabs has shipped" → here. Each product site keeps its product-specific changelog if it makes sense for its users, but the canonical company feed lives in one place.

For now, Trim's old changelog stays where it is. Won't touch the Trim repo without a specific signal. When the redirect decision lands, it's a five-minute edit on Trim's side.

What it cost to build

One TypeScript file holding 22 typed entries. One React component for the filter chips and timeline. One server-rendered Next.js route. Forty-five minutes of work, including writing this post.

The reason it took forty-five minutes and not three weeks is that all the data was already there. Trim's changelog source. AutoBrief's CHANGELOG.md. The journal posts. The git commit history. Consolidating things that already exist costs almost nothing. The expensive part is having the discipline to keep the source data clean as you go, so the consolidation is a one-evening job and not an archaeology project.

One feed. Four products. Color-coded. Filterable. Up at tarmaclabs.org/changelog now.

Share