The Engine Room — Inside the Content Distribution Engine

A trading engine I built files its own performance reports. It renders them, publishes them to a live site, and indexes them for search — and no human touches the editor. That sentence is the whole point of this post, but it only makes sense after you've seen the machine that makes it possible. So let's open the hood.

I'll walk it the way a reader actually moves through the questions: what can I publish, who gets to see it, where does it go, who writes it, and who owns the whole thing when the dust settles. Most platforms answer the first question and quietly fumble the rest. This one was designed around all five.

What you can publish

Most publishing tools give you one shape: the blog post. Everything else is a plugin, a hack, or a separate product you also pay for. This engine treats content as a typed system instead.

There are eight templates — Simple, Rich, Portfolio, Podcast, Changelog, Event, Book, Course — and they're not eight themes painted over one thing. They're eight content shapes the engine understands natively. A podcast knows it has episodes and a feed. An event knows it recurs, computes its own future occurrences from a single master URL, and never spawns a thousand duplicate pages that wreck your search ranking. A portfolio knows it's showing work, not telling a story. A course knows it has an order. The template isn't decoration — it's the engine knowing what a thing is, so it can render it, gate it, and index it correctly without you hand-building each one.

Underneath the templates sit nineteen composable block types — hero, stats grid, pipeline steps, feature grid, accordion, code, callout, gallery, screenshot slider, link cards, tech stack, video, audio, data-collection forms, and more. One block table, one resolver, one enum. The enum is the contract: every block is a known type with known rules, which is why the system can render, gate, and index any of them without a special case. You assemble a page the way you'd assemble anything well-engineered — from parts that compose, not from a pile of HTML you'll be afraid to touch in a year. A release note is a few text blocks and a code block. A product page is a hero, a feature grid, a stats grid, and a call to action. Same parts, different arrangement, every combination valid by construction.

There's also a microblog — short-form Thoughts with their own feed — for when the idea is a paragraph, not an essay. The long and the short live in one system, under one identity, on one domain. You don't run a blog and a separate place for quick takes; you run one surface that does both, so every fragment of attention you earn lands on property you own.

Who gets to see it

This is where the engine stops looking like a blog and starts looking like infrastructure.

Visibility isn't a checkbox here. It's ten composable access gates resolved on the server, on three axes that stack: the tier (public, registered readers, or pro), the group (horizontal segments — a cohort, a client, an inner circle), and a set of locks on top (password, unguessable secret link, scheduled publish, early-access windows, geographic rules, self-destruct expiry, registration walls). They combine, and the most restrictive one always wins, so you can always reason about access by asking "what's the tightest rule here" — the answer is the one that holds.

The detail that matters: gating happens before the page is serialized. A blocked reader's view-source is already clean — the protected body never left the server. That's not a policy promising your premium content won't leak. It's physics: it can't leak, because it was never sent.

In business terms, that's the difference between a paywall you hope holds and a boundary that's enforced in the wire. A stranger, a registered reader, and a paying member can hit the same URL and the server hands each of them a different, correct version of reality — and the site does that qualifying for you, automatically, before you ever take a call. That's a whole category of tooling — membership platforms, paywall services, gate plugins — collapsed into the engine itself. I devoted a separate piece to just this model, because it's the feature that turns a blog into a business; here it's enough to know the gates are real, server-enforced, and composable.

Where it goes

Publishing to one page in 2026 is table stakes; the value is in distribution, and distribution should be automatic.

Every post and Thought flows out through a dozen-plus channels without a second action: RSS and Atom feeds, a clean XML sitemap, structured share targets, and configured pipes to Telegram, Mastodon, and Bluesky. Featured images and social cards are generated automatically — including offline-rendered Instagram formats — so the work looks right wherever it lands. There's also webhook infrastructure for wiring the engine into systems you already run.

You write once. The engine fans it out. Nothing about your reach depends on remembering to cross-post at the right hour, and none of those channels can throttle what they didn't host. This is the inversion of the feed model: instead of pouring your work into one platform and praying it shows it to your own followers, you broadcast from your own surface outward to every channel at once — the open web as the hub, the platforms as spokes you control rather than landlords you depend on.

Who writes it

Here's where most platforms stop and this one keeps going.

First, personas. Your identity on the platform is decoupled from your login. One account can publish under several distinct public identities — each with its own name, bio, byline, and globally unique handle — and a reader sees the persona, never the account behind it. For a solo operator that means clean separation between, say, your technical writing and your essays, without juggling logins. For a publication it means many contributors under one roof, each with a real public profile, all managed from one admin. The login is plumbing; the persona is the face. One platform can host one author wearing several hats, or a masthead of many — same machinery, your choice of how to use it.

Then, agents — the part I'm most deliberate about. The engine exposes a typed ingest API, which means software can publish to it. Not "export to a file you upload later" — publish, directly, with the same access gates and the same typed blocks a human gets.

This is what lets a product write its own blog. Your software already produces signal — releases, reports, anomalies, briefings, results. Today that signal dies in a log file or a Slack channel nobody re-reads. Pointed at the ingest API, it becomes published, indexed, owned pages: a monitoring stack publishing its own incident briefings, a trading system filing its own performance reports, a research tool turning its findings into articles, a changelog that writes itself from your release pipeline.

And the agents don't get the keys on day one. Every API key sits on a trust ladder the server enforces. It starts in draft_only — everything it submits lands as a draft a human must approve, so a misconfigured agent embarrasses no one. Earn trust and it moves to tg_approval, where posts wait for a one-tap approval over Telegram — fast, but still a human in the loop. Earn more and it reaches auto_publish, fully autonomous. Per-key daily quotas cap how much any agent can post, minimum-quality checks reject thin submissions, and category limits keep an agent in its lane. The software has to earn its byline, the same way a junior writer would — and you can revoke that trust instantly if it stops deserving it.

That trading engine that files its own reports? It's at the top of that ladder now. It earned it — months of accurate, well-formed drafts before I let it publish unattended.

Who owns the whole thing

Everything above runs on infrastructure the operator controls. Self-hosted, Dockerized, single database, your domain, your backups. Ten theme presets across two visual families — a clean professional set and a terminal-flavored one — so the same engine can look like a fintech's pressroom or a hacker's lab without touching code. Full import and export, so your entire site is a file you can move, archive, or redeploy on a fresh box in an afternoon; your content is never hostage to the tool. And the build ships with 793 passing tests and zero type errors, because "ship deliberately" is a posture, not a press release.

Two things I won't oversell, because the discipline matters: there's no built-in email delivery or subscription billing yet — those are deliberately deferred, not quietly broken. I'd rather tell you exactly what runs and let you check it than pad the list. Everything I described above does run, in production, on the site you're reading.

The factory, and why it's the real product

Now back to the sentence I opened with.

Put the pieces together — typed content in, server-side access control, automatic distribution across a dozen channels, and agents that publish on their own once they've earned it — and you don't have a blog. You have a content factory. A machine that turns your product's own output into a compounding library of indexed, owned pages, which is the same thing as a compounding source of organic search traffic, which is the same thing as a lead pipeline that runs while you sleep and never sends a percentage to a platform.

Walk it through concretely. A B2B software company ships features every week and writes about almost none of them, because writing is a chore that competes with building. Point the release pipeline at the ingest API: every release becomes a changelog post, drafted by an agent, approved with one tap, published under the company's brand, structured for search, distributed to every channel. Six months later that's a hundred-plus indexed pages answering the exact questions prospects type into Google — "does X integrate with Y," "how does X handle Z" — each one pulling in a qualified stranger, each one owned, none of them rented. The content that used to die in a Slack thread is now the cheapest acquisition channel the company has.

That's the version of this I build for other people. Most companies pay for content twice — once to produce it, once to rent the distribution — and own neither at the end. The factory inverts it: produce once, distribute automatically, own everything, on your own brand and your own infrastructure. The CTO reads the architecture; the CEO reads this paragraph.

If a content engine running under your company's name — built, documented, and handed over to operate on your own terms — would change your numbers, that's a conversation I take on a few times a quarter. The engine is real, it's running, and you're reading this on it. The rest is your call.

Next, the person who built it — and why the work ships under a real name.

---

Summary

A full tour of the Content Distribution Engine — what it publishes, who sees it, where it goes, who writes it, and who owns it when the dust settles.

Typed Content. Eight native templates and nineteen composable blocks mean the engine knows what each thing is — and can render, gate, and index it correctly.

Server-Side Gates. Ten composable access gates resolve before the page is serialized; a blocked reader's view-source is already clean because protected content never leaves the server.

Automatic Distribution. Every post fans out through a dozen-plus channels — feeds, sitemap, Telegram, Mastodon, Bluesky — with no second action.

Personas and Agents. Public identities are decoupled from logins, and software publishes via a typed ingest API — earning autonomy step by step on a server-enforced trust ladder.

The Content Factory. Combined, the engine turns a product's own output into a compounding library of owned, indexed pages that pull qualified organic traffic.