The Portfolio
I run six products. Not six side projects. Not six landing pages with a Stripe button. Six products with real users, real infrastructure, real code signing certificates, real App Store review cycles, and real revenue models. Each serves a different audience, runs on a different stack, and demands its own operational cadence.
Here they are.
MVAT Focus is a Pomodoro-based focus timer for iOS and Android. Built with Expo (React Native), Firebase backend, Stripe plus react-native-iap for payments. The free tier gives you standard 25-minute Pomodoro sessions. Pro unlocks up to 120-minute deep focus blocks, cloud sync, themes, and ambient sounds for $4.99/month or $39.99/year. It is currently in TestFlight with an App Store submission under review, and running closed testing on Google Play.
MVAT Mirror is a zero-question personality profiling app. Instead of making you fill out yet another Big Five questionnaire, it analyzes your actual communication data — messages, emails, social media — to generate personality profiles from how you really behave, not how you think you behave. Expo SDK 52, Firebase, Zustand for state, on-device inference for privacy-critical processing. Raw personal data never leaves the device. The backend only receives anonymized personality vectors. Pro tier is $9.99/month or $49.99 lifetime. EAS builds are currently queued for the next submission cycle.
Agor.me — the site you are reading this on — is my AI consulting practice. Next.js 16 with React 19, a Gemini-powered chatbot with function calling, Google Calendar scheduling integration, automated podcast generation, and a markdown blog. Revenue comes from consulting engagements. The chatbot is not a gimmick. It handles initial qualification, answers questions about my services, and books calls directly into my calendar through the Google Calendar API.
ModelStack Digital is a digital product store selling business templates — Excel models, Word documents, PDF frameworks — to professionals who need operational tooling without building it from scratch. There are 35 products ranging from $20 to $200, organized across categories like financial modeling, AI workflow automation, SOP frameworks, and consulting playbooks. The architecture is deliberately primitive: static HTML on Netlify, Stripe Payment Links hardcoded in the markup, Netlify Functions handling webhooks and secure file downloads with HMAC-signed URLs. No framework. No build step. A GitHub Action generates a new blog post twice a week and sends a newsletter to subscribers. It works.
Aphor.me — the Subconscious Studio — runs AI-powered philosophical reflection sessions. Think of it as guided introspection with an AI interlocutor, not therapy but something adjacent to it. Next.js frontend, Stripe for session purchases, ElevenLabs text-to-speech for audio delivery. Sessions range from $9.99 to $29.99 depending on depth and format. The content pipeline combines philosophical frameworks with ambient audio design.
MVAT.ai is the brand site for the MVAT framework itself — the methodology that underpins how the agent system operates. It is a Next.js static site. Its purpose is not to sell anything directly but to establish the intellectual foundation that connects the other products.
That is the portfolio. Two native mobile apps. Three web applications. One e-commerce store. Five different revenue models. Three different deployment targets (App Store, Play Store, Netlify). And exactly one person operating all of it.
The Operating Model
The question everyone asks is: how? The honest answer is that I do not write most of the code. Claude Code does. But calling Claude Code an "assistant" would be like calling a CTO who works 24 hours a day, never forgets a codebase convention, and can spin up six parallel workstreams simultaneously an "assistant." The relationship is closer to what happens when a founder with strong product instincts pairs with an engineering team that has perfect recall and zero ego.
The operating model is not "I tell the AI what to do and it does it." The operating model is: I have built an institutional memory system — 42 custom skills, a 39-agent governance framework, structured artifact protocols, and layered autonomy levels — that allows Claude Code to operate as a full engineering organization with minimal human intervention.
There are specific rules that make this work, and I arrived at all of them through failure.
"Do, don't ask." The single most important operational directive. Dense instructions, no hand-holding. If I have to tell the AI to read the project's CLAUDE.md before making changes, the system is not working. The agent specs encode that behavior. Every agent re-reads its specification file at the start of every session. Every agent validates its inputs against structured artifact schemas before consuming them. The goal is autonomous execution with exception-based escalation — not a conversation.
Commit at milestones. Claude Code sessions can timeout. Context windows compress. If you wait until the end of a long session to commit, you lose everything. The rule is simple: commit after completing each significant chunk of work. WIP commits are fine. wip: implement payment flow for Mirror Pro tier is a perfectly acceptable commit message. The alternative — losing two hours of work because a session died — is not.
HANDOFF.md for continuity. When a multi-step task is taking many turns, the agent writes a HANDOFF.md in the repo root summarizing what was completed, the current state, and exact next steps. If the session dies, the next session reads the handoff file and picks up instantly without re-onboarding. This pattern alone has saved me more time than any individual tool or feature.
TypeScript check before every commit. In any TypeScript project, npx tsc --noEmit runs before git commit. If there are type errors, the commit does not happen. This is enforced by the operating rules, not by hope. The number of times this has caught a broken import or a mistyped interface is uncountable.
Maximize parallel agents for independent tasks. If I need to update the privacy policy across three products, fix a build configuration, and generate a blog post, those are four independent workstreams. They run simultaneously. Speed comes from parallelism, not from working faster sequentially.
A Day in the Life
Here is what a Tuesday looked like last week.
7:30 AM. I open my portfolio management dashboard — a Claude Code skill called portfolio-pm that runs health scans across all six products in parallel. Within 30 seconds, I have a status report: MVAT Focus App Store submission is still in review (day 3), Mirror EAS builds are queued, ModelStack had 4 sales overnight, Agor.me chatbot handled 2 inquiries, Aphor.me needs its SSL certificate renewed. Six products. Thirty seconds.
8:00 AM. The App Store review for MVAT Focus came back rejected the previous night. The rejection reason was a code signing issue — a provisioning profile mismatch between the EAS build configuration and the Apple Developer portal. I point Claude Code at the rejection email, the EAS configuration, and the Apple Developer account. It traces the mismatch to a stale distribution certificate, regenerates the profile, updates app.json, and triggers a new EAS build. Total time from rejection to resubmission: 40 minutes, most of which was waiting for the build to compile in the cloud.
8:45 AM. While the build runs, the automated podcast pipeline on Agor.me has already generated this week's episode. A GitHub Action triggered overnight: Anthropic's API generated the script from recent blog content, ElevenLabs synthesized the audio, and a Netlify Function packaged it and emailed the episode link to subscribers. I review the script for 5 minutes, approve it, and move on. A task that would require a content writer, audio engineer, and email marketer happened while I slept.
10:00 AM. I start building a new feature for Aphor.me — a session recommendation engine that suggests reflection topics based on previous session themes. Meanwhile, a parallel agent is writing two blog posts for ModelStack's automated content pipeline. I do not context-switch between these tasks. They run independently.
2:00 PM. The ModelStack posts are done. I scan them for accuracy — the product references are correct, the Stripe links are valid, the SEO metadata is populated. Quick approval. Meanwhile, the Aphor.me feature is in testing. The agent wrote the recommendation logic, the API route, the UI component, and the tests. I review the diff, suggest one UX change to the card layout, and it ships.
5:00 PM. I review agent-generated PRDs for next week's sprint. The product strategist agent has analyzed user feedback from TestFlight, cross-referenced it with the MVAT Focus roadmap, and produced three prioritized feature proposals with effort estimates, success criteria, and dependency maps. I approve two, defer one, and add a note about a design constraint the agent missed. That note gets logged in governance/corrections.jsonl — the primary learning signal for the system. Next time, the agent will account for that constraint.
The point is not that I am impressively productive. The point is that things which would require a 5-person startup — an iOS engineer, a content writer, a product manager, a DevOps specialist, and a web developer — are happening simultaneously, with one person making the judgment calls and the system handling the execution surface area.
What Claude Code Gets Right
I have used every AI coding tool that has shipped since GPT-3.5. Claude Code is the one I built a company on. Not because the underlying model is necessarily better at any single task, but because of four architectural decisions that make it extensible in ways the others are not.
The skills system. Claude Code skills are purpose-built tools that activate based on context. I have 42 of them. artifact-protocol enforces structured handoffs between agents. governance-reader loads the current state of kill switches, circuit breakers, and autonomy levels. pipeline-awareness gives agents visibility into where they sit in the 10-stage product lifecycle. product-conventions pulls the active product's CLAUDE.md so agents follow project-specific rules. Skills are not prompts pasted into a system message. They are modular capabilities that compose.
Sub-agents for parallelism. When I need research done while code is being written, those are separate agents running in parallel. When I need six products health-checked simultaneously, those are six sub-agents. The ability to fork work is not a nice-to-have. It is the fundamental capability that makes a solo founder viable. Sequential execution at human speed cannot cover six products. Parallel execution at agent speed can.
MCP servers. Model Context Protocol lets Claude Code reach into external services — Google Calendar, Gmail, Stripe, Netlify — as native tool calls. The chatbot on this site does not use a hacked-together API integration. It uses MCP to read my calendar availability and create events directly. When I deploy ModelStack, the agent calls Netlify's MCP tools. The seams between Claude's reasoning and external service execution disappear.
Hooks for guardrails. PreToolUse and PostToolUse hooks run before and after every tool call. My governance hooks enforce file ownership (only one agent can write to any given artifact path), rate limits (no agent exceeds its hourly action budget), and kill switches (I can disable any agent instantly by flipping a JSON value). These are not suggestions. They are enforcement mechanisms that fire on every single tool invocation. The system cannot violate its own rules because the rules are not encoded in prompts — they are encoded in hooks that intercept execution.
The key insight: Claude Code is not better because it is smarter. It is better because it is extensible. You can build an organization on top of it, not just a workflow.
What It Cannot Do (Yet)
I would be lying if I painted this as frictionless. It is not. There are real limitations, and pretending otherwise would make this post useless to anyone considering a similar approach.
Long-running tasks can lose context. Claude Code sessions have finite context windows, and complex multi-step work can exceed them. The HANDOFF.md pattern mitigates this, but it is a workaround, not a solution. When a session compresses its context, it sometimes loses subtle details that matter — a design constraint mentioned 40 messages ago, a specific edge case discussed during architecture review. The agent does not know what it forgot. You have to watch for drift.
Browser automation is fragile. Any workflow that requires interacting with a web UI — logging into the Apple Developer portal, navigating NotebookLM, filling out Google Play Console forms — is unreliable. Playwright crashes. Page layouts change. Auth flows add unexpected steps. I have had sessions where the Playwright browser automation for NotebookLM podcast generation crashed three times in a row before I gave up and did it manually. Browser automation works 70% of the time, which means it fails often enough that you cannot depend on it for critical paths.
Judgment calls still need a human. The agent system is excellent at execution. It is not good at deciding what to execute. When to ship versus when to polish. Which user feedback to act on versus which to ignore. Whether a feature is actually solving a real problem or just an interesting technical exercise. Whether the App Store rejection is worth fighting or whether we should just comply. These are taste decisions, and they remain firmly human. The 39-agent framework has explicit autonomy levels — L4 for auto-execute, with escalation paths for ambiguous situations — precisely because I learned the hard way that letting agents make judgment calls produces technically correct but strategically wrong outcomes.
The 80/20 of agent work. Roughly 80% of the tasks I delegate work beautifully. The agent reads the context, follows the conventions, produces correct code, and I merge with minimal review. The other 20% need babysitting. Complex state management across multiple services, nuanced UI interactions, anything involving platform-specific quirks (Apple's code signing ecosystem, Google Play's review policies, Expo's managed workflow limitations). For that 20%, I am not saving time — I am spending time differently, trading coding time for review and correction time. The net is still positive, but it is not the 10x multiplier that the hype suggests. It is more like 3-4x on average, with individual tasks ranging from 10x (boilerplate, scaffolding, bulk operations) to 0.5x (debugging a platform-specific issue where the agent confidently applies the wrong fix three times).
This is not a replacement for a team. It is a replacement for not having one.
The Bottleneck Shifted
Something happened over the past year that I did not expect. Engineering stopped being the bottleneck.
For my entire career as a builder, the constraint was always execution capacity. I had more ideas than I could implement. More features than I could ship. More products than I could staff. The fundamental scarcity was developer hours.
That scarcity is gone. Not reduced. Gone. I can implement any feature I can clearly describe. I can ship any product I can clearly spec. I can maintain any codebase I can clearly document. The execution surface area expanded by an order of magnitude.
And the bottleneck shifted to something I was not prepared for: taste.
What should I build? Not what can I build — I can build nearly anything. But what should I build? Which of the six products deserves the most attention this week? Which user feedback signals a real need versus a personal preference? Which feature will move the revenue needle versus which is technically interesting but commercially irrelevant? When should I add a seventh product versus deepen the five that exist?
These questions cannot be delegated to an agent. They require judgment built through direct conversation with users, aesthetic sensibility about what feels right in a product, strategic awareness of where markets are moving. The 39 agents can analyze data, generate options, and estimate effort. They cannot tell me what matters.
For a solo founder, this is actually the ideal bottleneck. Taste, judgment, and strategic vision are the things only I can provide. They are also the things that differentiate a product portfolio from a pile of software. If the bottleneck has to be somewhere, I want it to be at the layer where human insight is genuinely irreplaceable.
Claude handles the execution surface area. I handle the decisions. The division of labor is clean, and it scales.
What This Means
I want to be careful about the claims I make here. This is not a flex post. I am not trying to convince you that I am exceptional or that what I am doing is easy. It is not easy. Building the 39-agent governance framework took months of iteration. Writing 42 skills that actually compose correctly required understanding Claude Code's architecture at a level most users never reach. The operational discipline — HANDOFF.md files, TypeScript checks before every commit, structured artifact protocols — emerged from dozens of failures where sessions died, work was lost, and agents produced confidently wrong output.
But the data point matters. One person, six products, three platforms, five revenue models, real users, real revenue. The infrastructure to do this did not exist eighteen months ago. It exists now.
If one person can run six products, the economics of software companies change. The minimum viable team is one person with strong product instincts, operational discipline, and the willingness to build the agent infrastructure that replaces the rest. Not every person. Not every product. But for a meaningful class of software businesses — tools, content platforms, mobile apps, digital products — the solo-founder-plus-agents model is not a curiosity. It is a competitive architecture.
I wrote earlier this month about how the entire organizational structure of a company can be encoded in markdown files, and about how decision latency — the gap between knowing and acting — is now the defining metric of competitive fitness. This post is the practical companion to those arguments. The theory says that agent-orchestrated companies should be possible. The practice says that I am running one.
The gap between what is possible and what most people believe is possible has never been wider. That gap is where the opportunity lives.
I am looking for the right team to build this kind of tooling at scale. If you are working on developer tools, agent frameworks, or the future of AI-assisted development — let's connect.