What I'd tell someone who wants to build nine things at once

People ask me this more than any other question once they find out how many things I've built: how do you actually do nine at once? And the honest answer isn't a productivity trick. It's that building nine things is not nine times the work of building one thing. It's a different job, with different failure modes, and almost nobody tells you that going in.

So here's what I'd actually say, if someone sat down and asked me before they started.

The first thing that breaks isn't your time. It's your attention.

Everyone braces for the time problem. You won't have enough hours, so you'll cut corners, so quality drops — that's the story people expect, and it's not really what happens if you're using the model well. Claude Code will write the code faster than you can plan for it. The thing that actually runs out is attention, and attention doesn't refill the way time does. You can find another hour. You can't find another version of the focus you had at 9am once it's 4pm and you've context-switched through four different codebases.

What that means practically: the constraint on how many things you can run isn't "how much can I build," it's "how many separate mental models can I hold well enough to catch the model when it's wrong." That's a much smaller number than nine feels like it should allow, and I don't think I hold nine equally well. I hold them at different depths on purpose.

You will not give every project equal attention, and pretending otherwise is the actual mistake

This is the one I'd lead with. The instinct when you have nine things is to rotate through them fairly — a little time for each, keep them all moving, don't let any one fall behind. That instinct is wrong and it took me longer than it should have to admit it.

Some of these are live and earning attention from real users, which means a broken thing costs a real person a real afternoon. Some are built and sitting on a shelf waiting for the one test that only starts once I actually launch them — that's its own problem I've written about separately. Those two categories don't deserve the same hours. tab. being down for an hour is a different event than a shelf project's roadmap slipping a week. Treating them identically because "fairness" feels responsible is actually just avoiding the harder call of deciding, out loud, which one matters more this week.

So: rank them. Don't rotate them. And be willing to say a project got zero hours this week because something else needed all of them.

The model changes what "one more thing" costs, but it doesn't change what verification costs

This is the part that actually makes nine possible, and also the part people get wrong when they try to copy it. Claude Code collapses the build side of a new project down to something close to a weekend, if the shape of the thing is clear in your head. That's real, and it's the whole reason the roster grew this fast.

What it doesn't collapse is the checking side. Somebody still has to know whether the credit-report parser is reading Metro 2 fields correctly, whether the trading signal engine's backtest is actually representative or just overfit to one window, whether the community blueprint the model generated is something a real operator would want or just something that reads plausibly. Verification is the actual bottleneck, and verification doesn't get cheaper just because generation did. If anything, spreading yourself across nine domains makes verification harder, because the model is most confident exactly where you're least equipped to check it — and with nine domains, there are nine places where that gap can hide.

So the honest framing is: building got radically cheaper. Knowing whether what got built is actually right did not. If you're taking on more projects because generation is cheap, make sure you're not quietly taking on more domains than you can verify.

Naming things wrong is fine. Do it anyway.

A smaller thing, but it comes up constantly: half of what I've built has a name it didn't launch with. Sillage became Maison. SkoolOS became CommunityOS became CommunityHQ. MotionForge became Cadence Studios. Each rename felt like evidence I didn't know what I was doing when I started.

I don't think that's the right read anymore. You don't know what a thing is until you've built enough of it to see its actual shape, and the name you pick on day one is a guess made with the least information you'll ever have about the project. Waiting to name something until you're sure just means waiting to start. Name it wrong, build it, rename it when the wrongness becomes obvious. That's not indecision — that's the fastest way to learn what you're actually making.

The part that doesn't get easier: starting from zero, over and over

Here's the honest cost nobody mentions. Every one of these nine things started with zero users, zero audience, zero trust — and a portfolio doesn't transfer any of that between projects the way you'd hope. Having eight other things doesn't make the ninth thing's cold start warmer. If anything it can make it colder, because attention that could've gone deep into one launch gets split nine ways instead. That's worth being honest with yourself about before you start number two, let alone number nine: more shipped things is not the same as more momentum on any single one of them.

So, what I'd actually say

If someone's asking me whether to start their second, third, ninth project, the real question isn't "do I have time." It's: can I rank these honestly instead of pretending they're equal, can I actually verify what I'm shipping in this many different domains, and am I okay with each one starting cold regardless of how many others I've already got running. If the answer to all three is yes, the building part genuinely isn't the hard part anymore. That's the strange thing this year taught me — the bottleneck moved, it didn't disappear.