One Person Plus Agents: The Real Math of a Studio of One

The first version of this post was called “10 People Can Build What Used to Take 100.”

I’m retracting it.

Not because the direction was wrong. Because the numbers were a model dressed up as a report: a twelve-person team against a six-person team, burn rates, a “~40 people running a dozen businesses” operating model, cost tables to two decimal places. None of it was measured. And the number I actually have evidence for is smaller and stranger than ten.

It’s one.

What “alone” means

The Fractary is one person plus agents. No employees. No cofounders. The engineering, the product decisions, the customer conversations, and the writing are mine.

I’m going to be careful with the word “agents” too, because it’s easy to smuggle a team back in through it. Agents are not headcount. I won’t count them as people, because they aren’t, and because counting them hides the thing that actually constrains a studio of one. A team of ten has ten people’s hours and ten people’s judgment. I have one person’s judgment and a lot of leverage on the hours. Those are not the same, and the old post pretended they were.

The unit that matters

The old post modeled headcount and burn, because that’s how venture math has always been written. For one person, headcount is a constant. The unit that matters is founder-hours per venture: the hours a venture needs from me each week, against the hours it runs without me.

Here’s the dozen, honestly, by status. This is straight from the ventures page, which I keep accurate on purpose:

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

Five of the twelve are “in development,” which is a polite way of saying they’re waiting for my hours.

That table is the real math. Each week I look at it and ask one question: which venture, given a few of my hours, moves to the next status? The others wait, and I try to say so out loud rather than pretend they’re all moving. A live venture with its operations automated needs a few hours from me in a normal week. A venture in development needs whatever I give it and stalls when I don’t. The studio’s capacity is the sum, and the sum is bounded by one calendar. I’ll spare you a spreadsheet of my week, because a spreadsheet would look more precise than it is. The shape is what matters: every venture that runs without me buys hours for the next one.

Why people don’t scale linearly

Fred Brooks wrote it down in 1975 in The Mythical Man-Month: adding people to a late software project makes it later. Communication overhead grows with the number of pairs of people, and every pair needs to agree on what they’re building.

For a founder of one, communication overhead is zero. Nobody has to be told what I decided. That’s the single biggest structural advantage of building alone, and the old post barely mentioned it.

It’s also the ceiling. There’s no one to hand work to. Which is where agents come in, and where the second surprise is.

Why agents don’t scale linearly either

Agents are not free either, and the cost isn’t the API bill. It’s review.

In July 2025, METR ran a randomized controlled trial with sixteen experienced open-source developers working on their own large repositories. On the tasks where they were allowed to use AI tools, they took 19% longer. They had expected to be 24% faster. After the study, they still believed they had been about 20% faster.

I don’t think that study says agents are useless. I think it says something more useful: unreviewed agent output is fast and reviewed agent output is not, and reviewed is the only kind you should ship. The gain from agents isn’t “the work disappears.” It’s that the work moves from the doing column to the checking column. Checking is faster than doing only when the system is built to make it so: a spec to check against, tests that run without asking, a build that fails on the mistakes you’ve already decided you won’t make.

That’s why most of my engineering effort goes into the checking side. The content guard that fails this site’s build if a page contains a claim I’ve decided never to make exists because agents will confidently write things that aren’t true. So will I, at two in the morning. The guard doesn’t care who wrote it.

What I hand to agents, and what I keep

The line has moved over time. Here’s where it is now.

Agents do:

• Research and summarizing
• Scaffolding, boilerplate, and the first draft of almost anything
• Tests, and the tedious parts of making tests pass
• Keeping documentation in sync across repos
• Imports, data cleanup, and the kind of batch work that used to need an intern
• Running the build-and-verify loop and telling me what failed

I do:

• Decide what to build and what to kill
• Set prices
• Every customer conversation
• Every pull request review before anything ships
• Anything that becomes a public claim

That last one is the rule I’d pass on to anyone. An agent can draft the sentence. A human signs it.

The three claims I can actually defend

Strip the old post down to what survives contact with evidence, and three claims are left.

1. The floor dropped

A business that could never justify a single hire can now be run by one person plus agents. The Stockyard on this site is a small example: a directory of 865 tools, agents, and skills, imported from public collections by scripts, labeled by source, guarded at build time, with no staff. It doesn’t make money and isn’t meant to. It exists because I use it, and because one person can afford to run it. Ten years ago that directory would have needed someone’s job.

2. The ceiling is my hours

Anything that needs more hours than I have stalls. You can see this on the ventures page in the five “in development” entries, and you can see it in the sub-brand domains I’ve parked instead of linking, because a link to a dead site is a lie. Agents lower the floor. They don’t raise the ceiling much, because the ceiling is judgment and attention, and those don’t parallelize.

3. Starting compounds, finishing doesn’t

The shared stack means each new venture starts with everything the last one taught me: the agent definitions, the synced conventions, the deployment loop. The marginal cost of starting a venture is low, which is why there are a dozen. The marginal cost of finishing one hasn’t dropped nearly as much, which is why only two are live. The old post called this “efficiency compounding 2x, 5x, 10x, 15x.” The honest version is: starting got cheap, finishing didn’t, and a studio of one has to be disciplined about the difference or it ends up with twenty prototypes and no business.

What this means if you’re building alone

I’m not going to tell you one person can build what a hundred used to. I don’t know that, and neither does anyone selling it to you.

What I’ll tell you is this:

• Model your business in founder-hours, not headcount. It’s the number that’s actually true for you.
• Spend your engineering on the checking side, not the doing side. Agents already do the doing.
• Design every venture to buy back your hours before you start the next one. Otherwise the next one is where the last one stalls.
• Keep the judgment. Give away everything else.

That’s a smaller promise than the old title made. It’s also one I can keep.

Two doors

If you’re building alone and you’ve made it past $100,000 in revenue, The Foundry is a free, invite-only group of founders who’ve done the same thing, comparing notes on exactly this kind of math. The founding cohort is forming.

If you’re not there yet, and especially if you’re a teenager or have one, Make First is where I teach the version of this that starts with a first sale to a stranger.

---

This is the fourth post in a series on building for the agentic age. Previous: Building the Fractary Platform: Why I Open-Sourced My Stack. Next: Platform Limitations Are Your Prison: Master Your Systems.