July Systems Update: Owning the Publishing Path
Published: 2026-07-20 · Author: Tony Easterling
July has been less about adding another platform and more about making the system easier to own.
The site already held the builds, blog, and project history. This month I tightened the path around them: how a draft becomes a published issue, how a static site becomes a portable deployment, and how a playable experiment gets a clear public home.
The work is not flashy, but it reduces the number of places where the truth can drift.
What I built (and why it matters)
1) An owned newsletter archive
I replaced the old Beehiiv sync with a newsletter system that lives with the rest of the site. Published issues now come from structured local data, render through the site’s own reader, and can point people toward the active work without depending on a separate publishing archive.
That change makes the newsletter less of an external channel and more of a durable part of the home base.
2) A review gate that stays in the loop
The draft and publish scripts now have different jobs. One gathers current sources and creates a reviewable draft. The other refuses to publish until that draft is approved, and it checks whether the issue already appears to be live.
Automation should remove repetitive work without removing judgment. A clear approval boundary keeps the system useful and honest.
3) A portable Sites build
I added a build step that packages the static site and its public directories for Sites. That gives the project a repeatable deployment path without changing the simple HTML foundation that makes it easy to inspect and maintain.
The useful part is not the host itself. It is knowing the serving source, the build command, and the public files are explicit enough to move together.
4) Pixel Chomp moved from project page to playable proof
Pixel Chomp now has a public Sites build linked from its project page. The page documents the real stack—Phaser, TypeScript, Vite, and Capacitor—along with the current game loop, enemy system, and development path.
A build description is useful. A playable build is better evidence.
5) Fewer stale exits
I removed Facebook links from the site and newsletter publishing defaults. Keeping an inactive destination around does not make the system more connected; it makes the public record less accurate.
Every link is a small promise. If a destination is not active or useful, removing it is maintenance, not loss.
What I’m focusing on next
Lesson learned
Ownership is not the same as doing everything yourself.
It means the important path stays understandable: where the content comes from, what requires review, what gets deployed, and which public page tells the truth. External tools can still help, but the system should not become mysterious when one of them changes.
This month’s progress came from making that path shorter, clearer, and easier to verify.