How I Build 100 Apps Solo With Claude Code

I work alone. Yet I've spun up more than 100 projects so far, and about a dozen of them are actually launched and running. Design, code, marketing, operations — all of it, by myself.

This is possible not because I'm unusually fast. I didn't hire more people — I changed how I work. Claude Code is at the center of that. This post isn't "how to build one app with Claude Code." It's the whole system for building and running many of them on your own.

The system matters more than the tool

Using Claude Code doesn't suddenly let you build 100 things. Same tool, different results — the system is what separates them. When I take one from zero to running, the flow is always the same. That repeatable order is the point.

These seven steps are that system.

1. Check demand before building

The most common reason things die isn't a bug — it's that nobody wanted it. So before writing code, I check whether real people actually have the problem. If I can't see the demand, I don't build it.

This one step avoids the trap of "I can build it, so I will." You can build almost anything now. That makes "is it worth building" the more important question.

2. Get the design first (plan mode)

Vibe straight into code and bigger tasks drift. So I use Claude Code's plan mode to get a "here's how I'd build it" plan first — how to split the files, which existing patterns to reuse. I set the direction from that, then implement.

Catching a wrong direction at the plan stage is far cheaper than catching it in code. To run 100, this "cheap direction-setting" is essential.

3. Split the head from the hands

I don't do everything with Claude Code alone. Design and verification go to Claude, implementation to codex. Because when one model writes the code and the same model says "looks good," it misses what's wrong. I build a structure where a different engine verifies the other one's output.

I've written separately on why and how this split runs → I Don't Use Claude Code Alone — Splitting Work With codex

4. Catch the "pretends to work" with verification

The most dangerous thing about AI-written code is that it pretends to work convincingly. The screen looks fine while the thing underneath doesn't. So I don't trust "it's done." I run the build and the type check, click through it for real, then move on.

When you run many at once, the temptation to skip this is strong. But skipped verification always comes back more expensive after launch. So I don't compromise on it.

5. Bundle shipping into one repeatable job

This is where most people quit. App store assets, a privacy policy, a domain, search registration — a pile of work unrelated to code. Boring, but it's the gate that turns a demo into a product.

I keep this as the same procedure every time. No starting from scratch on each app, so shipping becomes "run the checklist" instead of "a big decision." Making it repeatable — that's the real trick behind shipping many.

6. Launch is the start of running it

To run a dozen at once, you can't hover over each one daily. So I set it up to alert me when errors happen and gather the numbers automatically. Instead of a person watching, the system watches.

Without that automation, even five becomes unmanageable. The premise of "make many" is "each takes little hands-on time."

7. Leave a record so you don't repeat mistakes

Problems I got stuck on and approaches that worked, I write down as I go. Claude Code loads CLAUDE.md from your working directory at the start of a session (walking up from the current folder to parent folders), so rules I put there save me from re-explaining the same things next session.

Run 100 and you can hit the same mistake 100 times. Write it down once and that becomes zero. The more this record grows, the faster the next project goes.

Most won't take off. So I wind them down responsibly

Honestly, even among the ones I ship, most don't take off. The reason that isn't fatal is that with AI, the cost of one is close to zero.

So I don't bet everything on one. But each thing I ship, I see through properly — all the way to launching and running it. If there's still no response after a real try, I don't leave it to rot; I wind it down cleanly and put that time into what does respond.

I've unpacked this "cheap, many, responsibly" strategy from a vibe-coding angle too → Vibe Coding to a Real Launch, Not Just a Toy

"Solo" means something different now

"Solo" used to mean "small, slow, one at a time." Not anymore. Split the designing head, the implementing hands, and the verifying eyes across tools, and one person can carry team-scale work.

The real value of Claude Code isn't "it writes code fast." It's that one person can run many things at once — and see each through, responsibly.

100 isn't the goal; it's the result. Build the system, and the count grows on top of it.