scsiwyg: A Blogging Platform Where the IDE Is the CMS

17 April 2026#worksona#portfolio#mcp#headless-cms#api-first#developer-tools

There is no text editor on scsiwyg.com. No draft management screen, no media upload dialog, no publish button. Content creation happens in the terminal, the IDE, or the AI coding assistant — wherever a developer already works.

scsiwyg is headless by design. The platform handles rendering, hosting, custom domains, newsletters, and billing. The creation layer is wherever you are.

This is a portfolio-level profile of scsiwyg as a Worksona project. The platform's own making-of series lives at /making-scsiwyg.

What It Is

scsiwyg is a Next.js 15 application deployed on Neon Postgres. Users sign up, receive an API token, and immediately have a blog at scsiwyg.com/{username}. From that point, every content operation — create, update, delete, schedule — happens through the REST API or through 21 MCP tools across two MCP servers.

The blog MCP server exposes 13 tools covering site management, post CRUD, contributor management, and content retrieval. The newsletter MCP server exposes 8 tools for the full compose-test-preview-send workflow. Both servers are instantiated per-request, stateless, using StreamableHTTP transport from the @modelcontextprotocol/sdk.

The web interface handles one thing: reading. Blog pages, post pages, account settings, billing, and MCP configuration. Nothing else.

Why It Matters

The practical consequence of headless design is that every capability the platform offers is equally accessible to a human typing curl, a CI/CD pipeline publishing changelogs on merge, and an AI assistant writing a post about the code it just helped ship. The API is not an afterthought — it is the only interface.

For the Worksona portfolio, this means scsiwyg functions as shared content infrastructure. Any portfolio project can publish through scsiwyg's API without building its own blogging system. A project ships a release; its pipeline posts the changelog. An AI coding session produces something worth documenting; publish_post is one tool call away.

The dual billing model — Stripe subscriptions and Patreon tier-based access, unified behind a single getUserPlan() function that returns 'free' or 'pro' — demonstrates that a developer tool can serve both traditional SaaS buyers and creator-economy participants without separate pricing logic for each.

How It Works

flowchart TD
    IDE["IDE / AI Assistant\n(Claude Code · Cursor · Windsurf)"]
    API["REST API\nPOST /api/{username}/posts"]
    MCP["Blog MCP Server\n13 tools · POST /api/mcp"]
    NewsletterMCP["Newsletter MCP Server\n8 tools · POST /api/mcp/news"]
    Auth["Bearer Token Auth\nScoped: read · write · admin"]
    DB["Neon Postgres\n8 tables · stateless HTTP queries"]
    Renderer["Next.js Renderer\n(read-only web interface)"]
    CustomDomain["Custom Domain\nMiddleware rewrite"]
    Newsletter["Newsletter System\nResend · double opt-in · RFC 8058"]
    Billing["Plan Resolution\ngetUserPlan()\nStripe or Patreon → pro"]

    IDE --> MCP
    IDE --> API
    MCP --> Auth
    API --> Auth
    NewsletterMCP --> Auth
    Auth --> DB
    DB --> Renderer
    Renderer --> CustomDomain
    DB --> Newsletter
    DB --> Billing

The database layer uses Neon's stateless HTTP driver. Every query is an independent HTTPS request with no persistent connection, no connection pool, and no connection leak on cold starts. This eliminates an entire class of serverless database failures.

Authentication is split cleanly into two independent paths: session cookies for browser-based account management, and Bearer tokens for all programmatic access. The scope system on tokens (read, write, admin) allows fine-grained access control at the tool level.

Sites support per-site theming with 10 presets, each defining 30 CSS variables for color and layout. Custom domains are handled by a single middleware rewrite — any non-scsiwyg.com hostname routes through a catch-all page that looks up and renders the correct blog. Community mode (communityOpen: true) turns any personal blog into a collaborative publication with role-appropriate contributor permissions.

Where It Fits in Worksona

scsiwyg is the portfolio's publishing layer and its first independently monetized product. It was extracted from a prior monorepo, establishing a reusable pattern for how future portfolio components can be separated, deployed, and monetized independently while remaining interoperable through standard APIs.

The MCP server patterns developed here — per-request stateless instantiation, Zod schema validation on every tool parameter, scope-based authorization, StreamableHTTP transport — are directly reusable reference implementations for any Worksona project that needs MCP integration.

The platform also acts as a proof point for the Worksona methodology itself: API-first architecture, headless design, and IDE-native workflows are not abstract principles here. They are the only way the product works. scsiwyg is, to our knowledge, the first blogging platform to expose MCP as a primary content interface. The bet is that as AI coding assistants become standard developer tools, the platform that lets them publish natively will occupy a durable position. That bet is already in production.

Live: scsiwyg.com

𝕏 Post