If you write and think about AI for a living, you eventually hit the same wall: LinkedIn and Substack own your audience, your archive, and your distribution — you’re a tenant, not an owner. I wanted a property I actually own (cogniflow-ai.com), where the domain, the database, and the publishing credentials are mine, and where a blog post, a curated prompt library, and a newsletter can all live under one roof instead of scattered across three platforms with three logins and three audiences that never overlap.

This isn’t just a personal itch. Any team or company building a public technical presence — a product blog, a developer-relations site, an internal knowledge base people actually search — runs into the same fragmentation: content ownership split across a CMS, a wiki, and an email tool, each with separate access control, separate backups, and no single source of truth for what’s published where.

The site runs on shared hosting (Aruba) as a full WordPress install, with a dedicated DokuWiki instance at wiki.cogniflow-ai.com/promptwiki for a curated, versioned library of prompt kits, and phpList wired up for newsletter distribution — three separate CMS/database pairs, each with its own admin login, living under one domain and one set of brand assets (logo marks, favicon, a custom splash template).

The front door is a custom WordPress page template I wrote by hand: a full-screen animated splash screen with a canvas-based node network drifting in the background (55 nodes, gradient edges, a soft glow and film-grain overlay), the “cogniflow” wordmark rising in on load, and two calls to action — Enter, which routes into the blog, and About. It ships in both a dark and a white variant and hooks into wp_head()/wp_footer() so SEO plugins and analytics still work normally through it — this isn’t a static landing page bolted onto WordPress, it’s a real page template inside the CMS.

The content itself isn’t hand-typed. A separate pipeline I built (the CogitOS “engine” project) logs into paywalled Substack sources via a persistent browser session, has Claude summarize each article and extract course-development ideas, and then writes WordPress-ready blog drafts — which get published here through a dedicated WordPress application-password account (`Research_Publisher`) scoped just for automated posting, kept separate from my own admin login. So the site isn’t just hosting; it’s the publish target of an automated research-to-blog-post pipeline, with a human still reviewing before anything goes live.

The unglamorous part turned out to be the real work: getting a splash page to survive being embedded inside WordPress (fighting theme CSS resets, hiding the admin bar, making sure wp_head/wp_footer still fire) taught me more about how fragile “just drop in custom HTML” is on a real CMS than any tutorial did. And separating the publishing credential from my personal admin login early — a distinct application password tied to a “Research_Publisher” account — was a small decision that mattered: it means an automated pipeline can post content without ever holding the keys to the whole site.

The planned next step is direct file-level import/export via FileZilla for pages that don’t belong in WordPress at all — static, hand-built pages that sit alongside the blog rather than inside it — plus building out the wiki and newsletter into real, populated properties instead of provisioned-but-empty shells. Longer term, the publisher could read directly from the pipeline’s article bundles instead of the current intermediate summary store, closing the loop between “Claude read this” and “it’s live on the site.”

The pattern generalizes past a personal blog: any org that wants an AI-authority presence — content marketing, developer relations, an internal technical wiki — faces the identical shape of problem: multiple content surfaces (blog, docs, curated reference, newsletter) that need one brand, one set of credentials policy, and ideally one pipeline feeding drafts in for human review rather than each surface being maintained by hand. Separating a scoped, low-privilege publishing account from admin access is a pattern worth stealing for any team wiring an LLM pipeline into a production CMS.