How I Use AI to Run a One-Person Product Studio

I maintain ~20 products. I've no engineering team. No co-founder for most of them. No virtual assistant. No outsourced development shop.

I've Claude, a set of MCP servers, and eighteen years of patterns stored in my head.

This isn't a humble brag. It's a new operating model that I think more builders should understand. AI doesn't replace the work of building products. It eliminates the work between building products: the context switching, the boilerplate, the repetitive operations, the administrative overhead that used to consume 60% of a solo founder's time.

Here's exactly how I use AI across every stage of my work.

The Daily Workflow

My typical day involves touching three to five products. Without AI, context switching between products would destroy my productivity. With AI, each product switch takes seconds instead of minutes.

Morning: Triage. I ask Claude to check the status of my systems. Through MCP servers connected to my databases, it tells me: "3 new contact messages on kingallem.com, 2 unread. LegalAgento has 14 new sign-ups since yesterday. Aviation Infinity's error rate is normal." This triage, which used to require logging into five admin panels, takes one conversation.

Deep work blocks. When I'm building a feature, Claude operates as a pair programmer. Not writing code for me, but thinking through architecture with me. "If I add jurisdiction-aware matching to LegalAgento, how should the database schema change to handle attorneys licensed in multiple states?" The conversation produces a design in minutes that would take an hour of solo whiteboarding.

Writing and content. Blog posts, product copy, email templates, documentation. I draft them in conversation with Claude. I provide the ideas, the domain knowledge, and the editorial judgment. Claude provides the first draft, the structure, and the consistency. The output is mine. The speed is AI-assisted.

Operations. Through MCP servers, I manage blog posts, CRM messages, and system administration through natural language. "Publish the regulated AI article." "Mark the message from John as replied." "Show me all draft posts." No admin panel needed for routine operations.

What AI Actually Does Well (For Me)

After two years of intensive AI-assisted development, I know exactly where AI adds value and where it doesn't.

Boilerplate elimination. Authentication flows, CRUD APIs, database schemas, admin panels, form validation. I've built these hundreds of times. AI generates them in seconds. Not because the code is trivial, but because the patterns are well-established and I can review the output for correctness faster than I can type it.

First-draft generation. Blog posts, product descriptions, error messages, email templates, documentation. AI produces first drafts that are 70-80% correct. My editing time is a fraction of what writing from scratch would take.

Code review and debugging. When something breaks, I paste the error and the relevant code into the conversation. Claude identifies the issue faster than I can trace through the stack because it can hold more context in working memory than I can. I still make the fix, but the diagnosis is AI-assisted.

Research synthesis. When I need to understand a new domain (trust account compliance rules, HIPAA requirements, aviation authority differences) AI can synthesize information from multiple sources faster than I can read the primary documents. I verify the synthesis against primary sources, but the initial understanding is dramatically faster.

Repetitive transformations. Reformatting data, converting between formats, generating test fixtures, updating configuration across multiple services. Tasks that are mechanically simple but time-consuming. AI handles them in seconds.

What AI Doesn't Do Well (For Me)

Product judgment. AI can't tell me whether a feature is worth building. It can list pros and cons, but the decision ("is this the right priority for this product at this stage?") requires context that only comes from years of building in the domain.

User empathy. AI doesn't know what it feels like to be a student pilot studying at midnight, or a single mother searching for affordable legal help. Product decisions that require emotional understanding of the user's situation are mine.

Architectural decisions. "Should LegalAgento use a microservices architecture or a monolith?" AI can discuss tradeoffs. But the decision requires understanding my team size (one), my operational capacity, my scaling trajectory, and my tolerance for infrastructure complexity. These are judgment calls, not information problems.

Quality threshold. AI doesn't know when code is "good enough" for a prototype versus when it needs to be production-grade. I do. The same feature might need different quality levels depending on whether it's an experiment or a core workflow. That calibration is human.

Domain-specific correctness. In regulated industries, AI-generated content needs verification. I can't trust AI output about aviation regulations, legal procedures, or medical workflows without checking against authoritative sources. AI speeds up the research; it doesn't replace the verification.

The MCP Server Ecosystem

The biggest force multiplier isn't Claude itself. It's the MCP servers that connect Claude to my systems.

I've MCP servers for:

• Blog management: create, edit, publish, unpublish, delete posts. Manage CRM messages. All through natural language.
• Database queries: check user counts, booking statistics, error rates. Quick operational dashboards without building dashboards.
• Content management: manage articles for multiple sites through a unified interface.

Each MCP server is a few hundred lines of TypeScript. The investment is small. The return (managing systems through conversation instead of through GUIs) is a huge win for a solo operator.

The key insight: MCP servers don't replace admin panels. They replace the 80% of admin work that doesn't need visual feedback. Changing a post's status, querying a count, updating a field: these are data operations. They don't need a browser, a login, or a GUI. They need a sentence.

The Economics of AI-Assisted Solo Building

Here's the math that makes this work:

Without AI: A solo founder can realistically maintain 2-3 active products while building 1 new one. Support, operations, bug fixes, and context switching consume 60% of available time. New development gets 40%.

With AI: The same founder can maintain 5-8 active products while building 2-3 new ones. AI handles boilerplate, first drafts, debugging assistance, and routine operations. New development gets 60-70% of available time.

The shift isn't about working more hours. It's about spending more of each hour on decisions that matter (product strategy, user experience, domain-specific logic) and less on implementation that follows established patterns.

The ~20 products I maintain aren't all active development. Some are stable and need only maintenance. Some are in growth mode and need features. Some are in early development and need architecture. AI lets me allocate attention across all of them without the overhead that used to make it impossible.

The Solo Founder Advantage

There's a counterintuitive advantage to being a solo founder in the AI era: zero communication overhead.

A team of five engineers spends 30% of their time communicating: standups, design reviews, code reviews, Slack discussions, alignment meetings. This overhead is necessary for coordination but produces zero product.

A solo founder with AI has zero communication overhead. Every decision is instant. Every context switch is private. Every architectural discussion is a thought, not a meeting.

This advantage won't last forever. As AI tools for team coordination improve, the communication overhead for teams will decrease. But right now, in 2026, the solo founder with AI tools has a speed advantage over small teams that's difficult to quantify.

What This Model Requires

This isn't a strategy for everyone. It requires:

Deep experience. You need to have built the same systems enough times that AI output is reviewable. If you can't evaluate whether AI-generated authentication code is secure, you can't use AI to generate authentication code. The patterns need to be in your head first.

Domain knowledge. AI can't compensate for not understanding your industry. You need to know the domain deeply enough to judge whether AI output is correct in context, not just syntactically, but substantively.

Discipline about quality. The temptation to ship AI output without review is constant. Every product I ship has been reviewed by me: every line of code, every piece of copy, every design decision. AI generates options. I choose and refine.

Comfort with imperfection. ~20 products means no product is perfect. Each one is good enough to serve its users well. But none of them are as polished as they would be if I dedicated 100% of my time to a single one. That tradeoff is deliberate.

The model works for me because I've been building for eighteen years and I know what I'm doing. AI multiplies capability. It doesn't create it. If you're early in your career, focus on building capability first. AI will be there when you're ready to multiply it.