About personal-presence-os

2026-04-01 · Updated 2026-04-04

The problem

Platforms optimise for themselves, not for creators. Your reach depends on algorithms you don't control. Your audience is scattered across Twitter, LinkedIn, Substack, Threads — each demanding a different format, each limiting how much of your own audience you actually reach. And when you want to leave, your content is buried inside systems designed to make moving on hard.

Meanwhile, a growing share of high-influence decision makers get their information from AI assistants, not search engines. If your expertise isn't structured where models can find it, you're invisible to that audience entirely.

What it does

personal-presence-os is a static content engine that runs multiple websites from a single codebase. Each site gets its own domain, its own content directory, and its own llms.txt file — a plain-text index designed for LLM crawlers to read.

You write Markdown with YAML frontmatter. The engine prerenders it to semantic HTML at build time. At runtime, a Hono server routes requests by Host header to the right site's static files. That's it.

The strategy

Your domains are the canonical home for everything you write. Platforms are distribution channels — you engage wherever your audience is, adapt to each format, but always link back to content you own and control.

This means cross-posting to Substack with canonical URLs, writing native posts on LinkedIn, sharing sharp takes on X — all driving traffic back to your sovereign content. If a platform changes or disappears, nothing is lost.

See the full distribution strategy for the playbook.

Goals

1. Own the content, own the audience. Publish across your own domains. Use platforms for reach, but never depend on them for durability.
2. Be findable by AI. Structured HTML, Schema.org JSON-LD, and llms.txt on every site — so your expertise gets cited when someone asks an AI assistant about your topic.
3. Measure before building. Self-hosted analytics (GoatCounter) across all domains tells you what resonates before you invest in engagement features. See the analytics setup.
4. Get fluent with Claude Code. The entire project is built with Claude Code as the primary development tool — architecture, implementation, content, deployment.
5. Practice extreme pragmatism. Ship fast. Learn in public. Every decision delayed is feedback not received.

Architecture

• sites.yaml is the single source of truth. Every domain, content path, status, and feature is declared there.
• Build phase: bun run build prerenders all active sites to dist/<domain>/.
• Serve phase: Hono reads from dist/ and routes by Host header. One process, all domains.
• Content: Markdown files with frontmatter. Pages, docs, log entries, decision records.
• Analytics: Self-hosted GoatCounter on the same VPS — privacy-friendly, no cookies, covers all domains.
• No frameworks: Vanilla JS web components only. No React, Vue, or Svelte.
• No cloud lock-in: Runs in any Docker host. Currently deployed on a Hetzner VPS behind Cloudflare.

Principles

The full list lives in PRINCIPLES.md. The short version:

• Prerender at build time, serve static files at runtime
• sites.yaml drives everything — never hardcode a domain
• Semantic HTML, Schema.org JSON-LD, llms.txt on every site
• Record non-obvious decisions; never delete history
• No frontend frameworks, no bundlers by default, no cloud-specific APIs

Stack