The Product Is Also the Story

Most developer tools have a blog they forget to update.

That's not a criticism. It's a structural problem. The blog lives in a different place than the work. To write about what you built, you have to leave where you built it, context-switch into a publishing mindset, reconstruct the thinking from memory, and produce something that sounds like you intended everything from the beginning.

By then, the honest version is gone.

scsiwyg started as a way to fix that for myself. An API-first blogging platform I could hit from the terminal, from Claude, from any tool that can POST JSON. No editor, no CMS, no tab to switch to. Write markdown, publish it, done.

But there's something more interesting happening in how the service itself evolves.

---

the dogfooding loop

Every post I write about building scsiwyg is published via scsiwyg.

This is the obvious version of eating your own cooking. The less obvious version is what it does to the product's narrative.

When you use your own tool to document its own evolution, the documentation is the marketing. Not because you're writing ads, but because you're demonstrating — post by post — exactly the workflow you're selling.

A developer reading this isn't reading a landing page. They're watching the thing work.

That's a different kind of proof.

---

what the evolution looks like

scsiwyg started as a single endpoint you could POST a JSON file to. That was enough for the original problem: publish from the terminal without leaving the editor.

Then the MCP server happened.

Once scsiwyg became an MCP tool — something an AI IDE could call natively — the surface area expanded. Now the AI that helps you write code can also help you write the post about the code, and publish it, without breaking context. The agent doesn't have to navigate to a web interface. It just calls publish_post.

That's a different product than "a blogging API." It's infrastructure for ambient publishing — the kind that happens consistently because the friction is low enough that you don't notice you're doing it.

The roadmap follows the same logic:

• reader/feed views, so the blog has an audience surface
• content types beyond posts — changelogs, release notes, devlogs with structured metadata
• webhooks, so external tools can react to new posts
• embeds, so a scsiwyg post can surface anywhere

Every one of those features is a response to the same constraint: the best publishing workflow is the one that happens inside the workflow you already have.

---

why this is also the marketing

The developer market doesn't respond well to "here's what our product does."

It responds to "here's someone using the product to do something real, and showing their work."

The arc of scsiwyg posts — from the frustration that started it, to the first working API, to the MCP integration, to whatever comes next — is the product story. It's not a launch announcement. It's a thread. Developers who encounter it partway through can read backwards. The whole build is there.

That's harder to fake than a polished product page. You either have the posts or you don't.

The service that lets developers publish from their IDE, consistently, without context-switching — that service generates its own evidence of the bet being worth making.

Every post is a data point. The collection is the argument.

---

scsiwyg isn't finished. The API works. The MCP integration works. The reader surface is next.

But the story is already running.

This post is part of it.