Why I'm Building 11 Apps as a Solo Developer

Eleven apps. One person.

I know how that sounds. It sounds like someone who can't focus. Someone who starts things and doesn't finish them. Someone who'd be better off picking one app and going deep.

Maybe. But here's why I'm doing it this way.

The Portfolio Thesis

Most indie developers build one app and bet everything on it. If it works, great. If it doesn't, you've spent a year on something nobody wanted.

I'm playing a different game. Instead of one big bet, I'm making a lot of small ones. Each app:

Solves a specific, narrow problem
Takes weeks, not months, to reach MVP
Has a clear monetization model from day one
Shares infrastructure with every other app in the portfolio

The idea isn't that all 11 will succeed. The idea is that some will, and I'll learn from the ones that don't. And the shared infrastructure means each new app costs less time and effort than the last.

The Shared Infrastructure

This is the part that makes the portfolio approach viable. Without it, 11 apps would be 11x the work. With it, each new app plugs into an existing system:

Identity docs. Every app gets an APP-IDENTITY.md that captures everything about it: features, pricing, audience, marketing angles, permissions, data collection. This document becomes the single source of truth for everything downstream.

Automated distribution. This website you're reading? It's generated from those identity docs. Write the identity doc, run a script, and the app gets a landing page, SEO metadata, structured data, and a blog. The content pipeline is one of the most valuable things I've built.

Legal pages. Privacy policies, terms of service, support pages — all templated and hosted on GitHub Pages. A new app gets legal coverage in minutes.

Payments. RevenueCat handles subscriptions across all apps. One dashboard, one integration pattern, one set of analytics.

Analytics. PostHog across every app. Same events, same dashboards, same patterns.

The first app took months. The tenth app will take weeks. That's the compounding effect of shared infrastructure.

What "Solo" Actually Means in 2026

I should be honest: "solo developer" doesn't mean I write every line of code by hand. I use AI extensively.

Claude helps me write code, debug issues, plan architecture, and generate content. The distribution engine that powers this website? Claude built most of it. The blog posts? Many are AI-generated drafts that I edit for accuracy and voice.

This isn't a secret or a confession. It's just how software development works now. The skill isn't typing code — it's knowing what to build, why, and how to verify that it actually works.

"Solo" means I make every product decision, own every user interaction, and take responsibility for every bug. The tools I use to execute those decisions are just tools.

The Honest Status

Of the 11 apps:

2 are nearly ready to ship (Voice Crumbs, AI Workout Timer)
3 are in App Store review (Hey Kitchen, PDF Pages, Sound Levels)
1 is in early development (Journeyman Voice Calcs)
4 are in concept/planning (HomeCOO, WTHooperAI, ScreenPact, Headroom)
1 is internal tooling (Vibe)

Am I spread too thin? Sometimes. The concept-stage apps get attention in bursts, not continuous focus. But the two that are ready to ship? Those got deep, sustained work. The portfolio model doesn't mean everything gets equal attention — it means I work on what's closest to shipping.

Following Along

I'm writing these State of the Studio posts monthly. If the portfolio experiment interests you — whether you're an indie developer, a potential user, or just curious — sign up for the newsletter.

I'll share what's working, what's not, and the actual numbers when I have them. No vanity metrics, no "crushing it" posts. Just the real story of trying to build a sustainable indie app studio.