Building PostConductor: Why I Pivoted to MCP-First

I'm dyslexic. Writing is hard. Always has been. A tweet that takes someone else two minutes takes me twenty. I lose words mid-sentence and can't find them again. Spelling mistakes I can't see because my brain fills in what I meant to type instead of what's there. It's frustrating, time-consuming, and the real cost is the gap it creates between what I want to say and what actually gets posted.

But I want to share what I'm learning. I want to post about the things I build. I want to engage with the communities I follow. The desire is there. The mechanics are the obstacle.

So I built PostConductor.

The gap PostConductor solved first

The gap was three things. Finding content worth sharing. Writing about it without the process taking forever. And getting it published at the right cadence without drowning my followers in a morning tweetstorm.

Finding content was a time sink. I follow a lot of sources: my own blog, YouTube channels, industry blogs, RSS feeds from frameworks and tools I use. Every morning I'd open tabs, scan headlines, read what looked interesting, and try to compose a thought about it. Most mornings I didn't have the time.

Writing was worse. The dyslexia meant I'd spend way too long on every post. Rewriting sentences. Fixing typos I couldn't see. Second-guessing tone. The cognitive load of "write something engaging" stacked on top of "just get the words right" was too much.

And then timing. Even on mornings where I got a few posts written, dumping them all at once felt wrong. Firehose posting doesn't build an audience. Spacing things out does. But spacing things out means remembering to post through the day. Another thing to track.

All of this is solved now. AI fixes the writing. Scheduling fixes the timing. But when I started building PostConductor, no single tool combined all three in a way that worked for someone like me.

How PostConductor v1 worked

Connect your RSS feeds. Your blog, YouTube channels you follow, articles from sites you read. PostConductor pulls in new content as it's published.

When you find something worth sharing, you write a quick note. Not a finished post. Just your raw take. What you think. Why it matters. Your opinion, in whatever form it comes out. Typos included. Half-sentences included.

AI takes your note, your opinion, and the source material, and writes the tweet. It structures it. Fixes spelling. Makes it engaging. Turns scattered thoughts into something coherent and postable. The thinking is yours. The writing is handled by something that doesn't struggle with the mechanics the way I do.

From there, posts go into a queue. PostConductor drip-feeds them to your X followers through the day. You don't post eight things at 9am and vanish. You appear consistently. The queue handles timing so you don't think about it.

This was working. I was posting more. I was engaging more. The analytics told me what my followers cared about. The machine was running.

The shift nobody planned for

Something changed. Not in a single moment. Gradually.

I found myself spending more and more time inside agent interfaces. Codex. Claude. OpenCode. The terminal became where I did most of my work. Web UIs started feeling slow. Clicking dashboards felt like friction compared to typing a command and getting a result.

I wrote about this shift in how AI agents made me CLI-first. The terminal became the universal adapter. Everything I needed was a command away. The browser became the thing I opened when a tool forced me to.

And then it clicked. Why was I building yet another web dashboard?

The BYOK problem

In PostConductor v1, I built an AI API gateway. Bring Your Own Key. Users connect their own OpenAI or Anthropic subscription. They pay for their own tokens. PostConductor orchestrates the workflow. People wanted this. Nobody wants to pay a markup on API calls they already have access to.

But the more I thought about it, the more wrong this felt. Why should people share their API keys with me at all? Why leave their agent interface, open a browser, log into a dashboard, and do the work there, when the AI they're already using could handle it?

The answer was MCP. Instead of asking users to bring their keys to my app, I bring my app to where they already work.

Going MCP-first

PostConductor is now an MCP-first application. You interact with it through the agent interface you already use. Draft posts. Generate tweets. Queue things up. All from your terminal, inside OpenCode or Claude or wherever you work.

The web UI is still there. But its role has shrunk to two things: subscription management and read-only analytics. You log in to manage your plan. You look at the dashboard to see how your posts performed. Everything else happens where you already are.

This is a bigger shift than it sounds. When you use a web UI, the app decides how you consume the data. The layout, the navigation, the information hierarchy. All designed by someone else. You adapt to it. When you interact through an agent interface, you decide. You ask for what you want, in your own words, and the system responds. The information architecture is yours.

This inversion matters. I've used enough SaaS dashboards to know that I spend most of my time navigating around things I don't care about to find the one thing I do. With the MCP interface, I just ask. Draft me a post about this RSS item. Show me my top tweets this week. Queue up three posts for tomorrow afternoon. No dashboard, no sidebar, no dropdown menus.

What this means for how I build

PostConductor was my first app where I made this choice consciously. Build the MCP interface first. Design the interaction model around how people actually work with AI. Treat the web UI as secondary.

I don't think this is right for every app. But I do think most of us are building web UIs out of habit, not because the problem demands it. We default to React and a dashboard because that's what building software has meant for the last decade. The agent interface changes that default.

The question I ask myself now for every new feature is not "what does the UI look like?" It's "how would someone ask for this in a conversation?" If I can answer that, the MCP interface is the right starting point. If I can't, maybe it needs a screen.

Web UIs aren't dead. But they're no longer the default. And that changes what we build and how we build it.