How I Run a Dozen Ventures Alone (What Alone Means)

“Alone” is a word I use carefully, because it’s easy to cheat with.

The Fractary is a venture studio with a dozen ventures and one person. That sentence gets a reaction, and the reaction is usually one of two things: “that’s impossible” or “so who actually does the work?” This post is my answer to both. It’s the operating manual, with the parts that don’t work left in.

What alone means

No employees. No cofounders. The engineering, the product decisions, the customer conversations, the pricing, and the writing are mine.

When I need something I can’t do, I buy it the way anyone buys a service, and that doesn’t make the person who sold it part of the studio any more than my hosting provider is.

The tempting cheat is to count the agents. I run a lot of them, and on a good day they do most of the hours of work that happen here. But agents are not headcount. A team of ten has ten people’s hours and ten people’s judgment. I have one person’s judgment and a great deal of leverage on the hours. If I let “one person plus agents” quietly become “a team of eleven,” I’d be back to the kind of math I already retracted.

So the honest description is: one person’s judgment, applied through systems, to a dozen ventures at very different stages.

The dozen, honestly

Here they are, by status. This is copied from the ventures page, which I keep accurate because a status label is a promise.

Status	Ventures
Live	Win IRL, Grocelytics
Private beta	Corthos
Prototype	VoxBuy, eCollective
Preview	Org Strong
Private alpha	OmniDAS
In development	Infactas, Truefita, Open Costs, Locutos, Neighbor Hold

Two live. Five that are, in plain language, waiting for my hours. That ratio is the most honest number on this site, and the rest of this post is about why it looks like that and what I do about it.

What runs without me on a normal day

I only list things here that actually run. If it needs me to press the button, it’s in the next section.

This website builds, checks, and deploys itself. Every merge to the main branch triggers a build. The build runs a type check, generates the site, builds the search index, and then runs a content guard: a script that scans every generated page for a list of strings I’ve decided must never appear, and fails the build if it finds one. If the build passes, the site deploys. If it fails, nothing changes and I get told. I don’t watch it.

Shared documentation stays in sync. The conventions that agents work from live in one place and are distributed to the repos that need them by Codex, according to rules in each file’s frontmatter. When I change a rule, every repo that uses it gets the change. This site’s repo has a folder of documents it didn’t write for exactly that reason.

The Stockyard doesn’t need a curator. The directory has 865 listings. I added 23 of them by hand. The rest came from import scripts that pull from public collections, label each listing with its source, and let the build guard reject anything that breaks the rules. I choose which sources to trust. I don’t type listings.

Each venture has its own version of this, and the specifics are different enough that they deserve their own posts.

What still needs me, every day

Every customer conversation. I don’t put an agent between me and a person who’s paying, or thinking about it. Agents draft; I talk.

Pricing. No system sets a price here.

What to build, what to park, what to kill. The status table above is the output of those decisions, and they’re the ones I’d least want to hand off.

Every pull request. Nothing ships to any venture without a human reading the diff, and the human is me. Agents build; I review. That review is the single largest recurring cost in the studio, and I’ve written about why it doesn’t go away.

Every public claim. An agent can draft the sentence. I sign it. The content guard exists because agents will confidently write things that aren’t true, and so will I at two in the morning, and the guard doesn’t care which of us did it.

The shape of a week

The studio’s working method has a name and five phases: Frame, Architect, Build, Evaluate, Release. It’s the workflow the studio’s own Faber tooling encodes, and it’s how every change here ships, whether it’s a feature in a venture or a paragraph on this site.

A normal week looks like this:

Monday, decide. I look at the status table and ask one question: which venture, given a few of my hours this week, moves to the next status? One or two get hours. The others wait, and I try to say so rather than pretend they’re all moving.

Frame. For whatever got picked, I write down what’s changing and why, including the decisions I’ve made and the claims I won’t make. When this site was repositioned in early September, that was a spec with a decision table: what the studio is, what it isn’t, what’s live and what’s coming soon.

Architect. A plan: which files, which data, what the check is that proves it worked. Writing the check before the code is the habit that changed the most for me since agents arrived.

Build. Claude Code does the building on a branch, with the studio’s conventions synced in so it knows the rules without my repeating them. I’m nearby, but I’m not typing.

Evaluate. The checks run: types, build, content guard, a link checker for the ventures. If they fail, the agent tries again before I look.

Release. A pull request. I read it. It merges. It deploys. I move to the next thing.

The whole loop for that repositioning, spec to deploy, was five pull requests over three days. I’ll walk through that week, commit by commit, in a later post.

Why adding people wouldn’t have helped

The obvious question is why I don’t just hire. Three reasons, in order of honesty.

The math is against it. Fred Brooks wrote it down fifty years ago in The Mythical Man-Month: adding people to a late software project makes it later, because the communication overhead grows faster than the output. With one person, the communication overhead is zero. Nobody has to be told what I decided. That’s the single biggest structural advantage of building alone, and it’s the one people underrate.

Agents already took the work a hire would have done. The routine parts of building software are exactly the parts agents are good at. What’s left is judgment, and judgment doesn’t divide well.

Managing is the job I’m trying not to have. I’ve done it. I’m not building a studio so I can do it again.

None of that makes agents free. In July 2025, METR ran a randomized trial in which experienced developers were slower with AI tools on their own codebases while believing they were faster. My reading is that reviewed agent output costs review time, and reviewed is the only kind you should ship. The leverage is real, but it comes from moving discipline into the system so that checking is faster than doing. That’s the whole trick, and it’s a practice, not a purchase.

Where it fails

I’d be lying if I ended there.

Ventures stall on my hours, not on the tools. Five in development is what that looks like. Nothing about the stack prevents those from moving. I do, by choosing to spend the week elsewhere.

Parked domains. Several sub-brands under the ventures have domains that don’t resolve yet. On the ventures page, those chips aren’t linked, and in the data file behind the page they’re parked with a dated note, because a link to a dead site is a lie. That list is the honest record of things I started and haven’t finished.

Starting is cheap, finishing isn’t. The shared stack means each new venture begins with everything the last one taught me. That’s why there are a dozen. It’s also the trap: a studio of one has to be disciplined about the difference between starting and finishing, or it ends up with twenty prototypes and no business. I’m not fully out of that trap. Two live is the proof.

If you build alone

I’ll keep this short, because the point of the series is to show rather than tell.

• Model your business in founder-hours, not headcount. It’s the only number that’s actually true for you.
• Only list as “running” the things that run without you. Everything else is a task, and tasks cost hours.
• Spend your engineering effort on checking, not doing. Agents already do the doing.
• Decide on Monday which one thing gets your hours. Say out loud what’s waiting.
• Keep the customer conversations, the pricing, the kill decisions, and the review. Give away everything else.

If you’ve built a business alone and made it past $100,000 in revenue, you already know most of this, and you probably have a better version of some of it. That’s what The Foundry is for: a small, free, private group of founders in that exact position, comparing notes. The founding cohort is forming, and I read every request myself.

---

This is the first post in the Studio of One series. The earlier series, Building for the Agentic Age, covers the thinking behind it, and One Person Plus Agents covers the math.