SingleClickBlog — Faust.js + WordPress

The Authoring Surface Problem, Solved

Three blog iterations led to this conclusion: the editing experience is the product. Sanity's Content Studio was technically correct but felt like a database form. Hygraph GraphQL was an improvement but still too structured for comfortable long-form writing. My brother knew WordPress. WordPress's editing experience is mature, battle-tested, and familiar to anyone who has ever maintained a blog. The right answer was to keep WordPress as the authoring surface and replace the frontend entirely.

Headless WordPress is the architectural pattern: WordPress handles content creation and management, WPGraphQL exposes that content via GraphQL, and a Next.js 14 frontend handles rendering. Faust.js provides the Next.js data-fetching layer pre-configured for WPGraphQL, handling the authentication handoff and routing integration that would otherwise require custom plumbing.

The Technical Layer

graphql-codegen generates TypeScript types directly from the WPGraphQL schema at build time. That single decision eliminated an entire category of type errors: the TypeScript shape of every post, category, author, and custom field is always in sync with what WordPress actually returns. When the schema changes in WordPress, the types update in CI. No manual interface maintenance.

Apollo Client manages GraphQL data fetching and caching on the frontend. Redux Toolkit stores client session state for the authenticated author view. The Tiptap rich-text editor provides the authoring interface in the Next.js admin surface — a deliberate alternative to relying entirely on the WordPress dashboard for composition. Tiptap posts back to WordPress via the REST API.

Self-hosted WordPress runs on Coolify. The Next.js frontend deploys to Vercel. 29,862 lines of code, production configuration for both environments.

The Honest Verdict

The architecture is correct and the separation of concerns is clean. The maintenance overhead is real: two deployed systems (Coolify for WordPress, Vercel for Next.js), schema synchronisation via codegen in CI, authentication across the boundary. For a solo writer who wants to publish without managing infrastructure, the operational overhead is too high.

The verdict landed me at the Karmpath thesis: build the CMS. Instead of integrating around multiple existing systems, build a single publishing platform where the authoring experience, the data model, and the rendering layer are designed together. SingleClickBlog made the trade-offs of headless WordPress concrete and showed exactly what a purpose-built alternative would need to improve.