Independent Publishing & Commerce System

KXTX began as a refusal to let the work be shaped by platform logic. I wanted essays, fiction, visual identity, and physical objects to meet readers on their own terms, without being flattened into one generic content type, routed through an algorithm, or bent around the limits of a CMS.

So I built both an independent publishing operation and the software underneath it. I wrote and edited the publication, designed its brand and products, built the software, and ran merchandising and day-to-day operations. The final recovered catalog contains 39 essays across eight categories and 14 installments across three fiction series. Two long-form artifact editorials bring the authored total to more than 65,000 words. The supporting application contains roughly 5,300 lines of PHP, JavaScript, CSS, and Python.

This was not a portfolio demo dressed up as a product. It published real work, sold original apparel, and maintained a live catalog. Every part of the operation, from a sentence to a product page, had a place inside one coherent system.

One idea, three publishing modes

The organizing idea was simple. Essays make the argument, fiction dramatizes it, and artifacts carry it into object form. They belong to the same symbolic field, but they do not ask a reader to behave in the same way.

Essays needed categories, dates, featured curation, and optional audio. They also needed paths into related reading. Fiction needed ordered series metadata, issue or chapter labels, cover identities, and a reader that could move through a work without losing its series context. Products needed live prices and images from Shopify, but also enough local editorial space to mean something beyond a catalog listing.

The platform keeps those data models distinct while sharing a stable page shell, typography system, responsive behavior, and navigation. Media controls, sharing, error handling, and reusable PHP components are common across the site. The fiction series receive distinct identities at their covers and hubs, while the common reading surface stays quiet enough for the work itself.

Markdown as the source of truth

The writing lives as ordinary Markdown on disk. PHP renders it on the server through shared essay, chapter, about, and product-editorial templates. JSON manifests hold route IDs, categories, display titles, and dates. They also control series order, labels, descriptions, and curated selections.

I built a Python publishing tool to reconcile those layers. It scans the category tree and compares the filesystem with the existing manifest. Hand-edited titles and ordering remain intact. The tool reports additions, removals, metadata changes, and missing or stale routes. Dry run is the default. When explicitly committed, it writes the JSON manifest through a temporary file, creates the tiny PHP route stubs that connect content to the shared renderer, removes only files it can identify as generated wrappers, and rebuilds the essay section of the sitemap.

The runtime enforces the same contract. An essay is public only when both its manifest entry and Markdown source exist. A stale wrapper does not return a friendly-looking 200 page for missing content; it becomes a real 404. The public JSON endpoint also filters missing sources before the browser ever sees them.

Editorial discovery without a CMS

The homepage resolves a small, ordered list of featured IDs against the full essay manifest, preserving editorial judgment without duplicating content records. The writing index fetches the live manifest and featured list together, builds category controls from the data, and renders its cards from a reusable template. When a reader returns from an essay, the interface remembers the last item and restores their position.

Essay pages discover images and optional audio beside the Markdown source, assemble bounded “more essays” navigation from the manifest, and offer one-to-one email sharing instead of an engagement feed. Fiction uses the same principle at a series level: structured chapter manifests, a shared renderer, ordered navigation, and metadata that stays synchronized with the current installment.

The interaction layer is deliberately small and modular. Core navigation and icon hydration run everywhere. Filtering, media playback, product catalogs, and image zoom load only on pages that use them. Pages load metadata synchronization and email sharing only when needed. File modification times version local assets automatically, so deployment does not depend on a frontend bundler to invalidate the browser cache.

Commerce behind the editorial layer

Shopify handled the product catalog and sale, but it did not own the publishing experience. A server-side Storefront GraphQL adapter normalized product titles, handles, and prices into the site's own shape. It normalized tags, descriptions, and primary images the same way. The catalog response was cached for five minutes to keep ordinary browsing fast and reduce API traffic.

A Shopify tag selected the featured artifact. The rest of the catalog received ordered display numbering and reusable cards. Product pages combined current Shopify data with local Markdown editorials, a high-resolution image viewer, and related products. Private sharing and an outbound order path completed the page. The result was a store whose objects remained part of the publication's argument rather than interrupting it with a separate retail template.

Owning the whole surface

Running KXTX meant handling responsive navigation, canonical URLs, custom error pages, and a public PGP contact surface. Local analytics and sitemap generation were part of the same operation. Caddy returned 404s for source Markdown, configuration, internal components, and publishing tools.

The publication was deployed through the application platform I operate from home. Cloudflare-proxied DNS and automated dynamic-IP updates kept the residential endpoint reachable. Caddy served an isolated PHP runtime on a repurposed ThinkPad behind a default-deny firewall. Services were monitored, and deployment history remained recoverable. Shopify handled product data and checkout; it did not host or define the publication.

The operation closed in July 2026, and the original domain is no longer presented as live. What remains is a complete snapshot of an unusually integrated project. I wrote the publication, created its visual and editorial identity, and built the publishing toolchain and reader application. The commerce layer served the same idea and belonged to that end-to-end work.

What this demonstrates

• End-to-end ownership across editorial strategy, brand, interaction design, product design, engineering, merchandising, and operations
• A dry-run-first content compiler that reconciles Markdown, JSON manifests, generated PHP routes, and the sitemap
• Manifest-gated server rendering with real 404 behavior, reusable reading surfaces, curated discovery, and optional media
• Shopify Storefront GraphQL integration with server-side caching and local long-form editorial layered into live product data
• PHP and JavaScript architecture with modular page behavior, responsive components, and automatic asset versioning
• Public home-hosted operation across Cloudflare, dynamic DNS, Caddy, an isolated PHP runtime, monitored deployment, and recovery
• More than 65,000 words of long-form editorial and fiction supported by a purpose-built platform rather than a generic CMS