Back to Blog
velocitysolo studioai-nativeproofmacro thesis

One Person AI Software Studio: A Full Quarter of Proof

1,900 commits, 31 new products, one operator in 90 days. What a one person AI software studio actually sustains, not just sprints.

By Mike Hodgen

Short on time? Read the simplified version

The Number That Sounds Like a Stunt

Here is the raw number. In about 90 days, working as a one person AI software studio, I pushed roughly 1,900 commits across 49 active repos and bootstrapped 31 brand-new products from zero. One operator. No team. No contractors.

If you are a CEO and your first reaction is to discount that on sight, you are right to. It reads like a viral stunt. The kind of thing someone does for one frantic week, screenshots, and posts to get attention before going quiet for a month.

That default suspicion is correct most of the time. I have watched plenty of "look what I built" posts that turn out to be a single demo dressed up as a capability.

So I will not ask you to take the number at face value. I already published the smaller versions of this and watched people dismiss them.

A while back I wrote up 808 commits in 30 days. Before that, I documented what one week of AI-first building looks like, ten projects, seventy-two commits. Both got the same shrug from skeptics: nice sprint, anyone can sprint.

And they had a point. A week proves nothing. A month is borderline. Either one can be powered by adrenaline and a backlog of obvious work you had queued up.

So this post answers the only question that actually matters. Is this a stunt, or is it a sustained baseline? A quarter is long enough that the adrenaline runs out and the easy wins dry up. That is exactly why I am using it as the test.

No hype here. Just the data and an honest read of what it does and does not prove.

Why a Quarter Is the Only Honest Test

A sprint proves enthusiasm, not capacity

A week of high output proves you were excited. A month proves you had a backlog of obvious work and the energy to clear it.

Neither tells a buyer what they actually need to know. The real question is whether the pace holds when the easy stuff is gone. When you get sick. When one project goes sideways and eats three days. When motivation dips on a Tuesday for no reason.

That is the gap between a sprint and an operating mode. Anyone can sprint once. Almost nobody can hold a broad pace for a quarter without something cracking.

What degradation would have looked like

I knew exactly what failure would look like in the data, because I have seen it in other people's output.

Line chart contrasting a declining stunt commit pattern against a flat sustained baseline across a 90-day quarter Stunt vs Sustained Baseline (commit curve shape)

Commit counts taper week over week. The first week is huge, the fourth is half that, the eighth is a ghost town. Projects stall at 80%, the boring last mile where there is no dopamine left. Repos go quiet after the exciting first sprint, abandoned at the exact moment they needed the unglamorous finishing work.

If this had been a stunt, the quarter would show that shape. A spike, then decay.

It did not. Across roughly 90 days the pace held and, more importantly, the breadth widened. New domains kept getting added instead of the same few repos getting padded.

Let me be honest about the texture. Some weeks were lighter than others. There were stretches where I shipped less because I was thinking through an architecture problem or, frankly, because life happened. The peak days are not the signal. The average is.

That is the whole point of measuring a quarter instead of a week. Averages survive the bad days. A sprint number does not. When you look at the sustained average and it holds across three months, you are no longer looking at enthusiasm. You are looking at capacity.

31 Products Across Industries That Have Nothing in Common

The breadth is the claim, not the count

The number 31 is not the interesting part. The interesting part is that those 31 products span industries with nothing in common.

Regulated healthcare workflows. Financial tooling. Ecommerce operations. Field-service trades. Legal intake. Consumer mobile apps. Marketing automation.

Those domains share no business logic. The compliance constraints in healthcare have nothing to do with the scheduling math in field service. Legal intake and consumer mobile are different planets.

If all 31 products were variations on one theme, say, 31 flavors of the same SaaS dashboard, the count would be inflated and basically meaningless. You can stamp one template thirty-one times and call it productivity. That proves nothing.

Why unrelated domains matter to a skeptic

The fact that these span unrelated verticals is what proves the capability is general, not a single trick repeated. This is the argument I made in range beats depth now, and the quarter is the proof of it.

Diagram showing seven unrelated industries all built on five shared technical primitives: auth, database, payments, AI orchestration, deployment 31 products across unrelated industries on shared technical primitives

A skeptic should care about this specifically. If I could only build in one domain, I would be a specialist with a narrow tool. The breadth says the underlying method transfers, that dropping into an unfamiliar industry and shipping something functional is repeatable, not lucky.

Now the honest part. The same five or so technical primitives underpin most of these products. Authentication. Database. Payments. AI orchestration. Deployment.

That is exactly why range is possible without me becoming a domain expert in seven industries. The business logic differs, but the plumbing rhymes. I am not relearning how to ship every time. I am re-applying a known foundation to a new problem.

That is not a weakness in the claim. It is the mechanism behind it. Range comes from reusable foundations, not from infinite expertise.

What Made the Pace Sustainable (Not Heroic)

AI does the typing, the operator does the deciding

Let me kill the burnout assumption directly, because it is the first thing people reach for. "You must have destroyed yourself for three months." No.

Comparison table of mechanical work AI absorbs versus judgment and decisions that stay human What AI does vs what stays human

The reason this is repeatable is that AI absorbed the mechanical labor. Boilerplate. Schema migrations. Test scaffolding. Refactors. The glue code that used to eat entire afternoons.

My time went to the parts AI cannot do. Decisions. Architecture. Judgment calls about scope and tradeoffs. The work that actually requires a human stayed human. The typing got delegated.

Here is the concrete version. In my own DTC fashion brand, my product-creation pipeline went from 3 to 4 hours per product down to about 20 minutes. That did not free me to relax. It freed me to direct more projects instead of executing fewer.

That is the shift. AI did not make me work less. It changed what I spend my hours on.

Reused infrastructure, not reinvented wheels

The second reason the pace held is that I do not start from zero. Across 49 repos, the reused primitives mean each new product starts at roughly 60% done.

Bar showing a new product starts 60 percent done from reused foundation with only 40 percent problem-specific work 60% reused foundation + 40% problem-specific work

Auth is solved. The payment integration pattern is solved. The deploy pipeline is solved. AI orchestration follows a structure I have already debugged a dozen times. So a new product is not a blank page. It is a known foundation plus the 40% that is actually specific to this problem.

That is the difference between an operating system and a grind. A grind is doing the same hard setup over and over. An operating system is paying for that setup once and reusing it.

The honest limit: this works for building and shipping. It does not replace the slow work of finding the right problem to solve. I can build fast. Knowing what is worth building is still the slow, human bottleneck, and it should be.

What the Commit Count Does Not Tell You

Commits measure motion, not value

Let me undercut my own headline number, because that is the only honest thing to do.

Infographic distinguishing 1,900 commits as motion from 31 shipped products as real output, with caveats Commits measure motion, shipped products measure output

A commit count is a vanity metric on its own. I could pad it trivially. Split work into more commits, commit more often, automate trivial changes. The number 1,900 means nothing by itself.

What actually matters is that 31 products went from nothing to functioning, and that the throughput held across a quarter. The commits are evidence of motion. The shipped products are evidence of output. Do not confuse the two.

The decisions AI couldn't make

Here is the part the count hides entirely.

Not every product is a winner. Some are experiments. Some will get killed. Velocity is not product-market fit, and I would be lying to you if I pretended every one of those 31 things is going to matter in a year.

Some of them exist to test an idea fast and cheap. Building something in days instead of months means I can find out it is wrong without much sunk cost. That is a feature. But it means the count includes things that will not survive contact with reality.

And the hard parts are still slow. Pricing calls. Scope cuts. Deciding what not to build, which is harder than deciding what to build, and AI is no help there at all.

Those decisions are still mine, still human, and still take real thinking time. The velocity is in the execution. The judgment is the part that does not speed up. Anyone telling you AI handles the judgment too is selling you something.

What This Means for a Company That Hires Help

Sustained output, not a one-time project

If you are a CEO, you do not actually care about my repo count for its own sake. Fair enough. So let me translate the dataset into terms that matter to you.

What you care about is whether the person you bring in can hold a pace across the messy, multi-front reality of your business. Whether they flame out after the exciting kickoff. Whether they go dark when the work gets boring.

That is the real fear with any outside help. The first month is great. Then the energy fades, the responses slow, and you are managing them instead of the other way around.

A quarter of sustained, broad output is the answer to that fear. It is the difference between a demo I performed once and a baseline I operate at every week. The whole reason I measured 90 days instead of 7 is so I could show you the difference.

What you can actually rely on

What you can rely on is this: I build the systems. I do not just produce a slide deck about what you should build. That distinction is the whole thing, and I wrote about it in I build it, I don't just advise on it.

The output you just read about is what that looks like over a real timeframe, applied to real problems, across industries that look nothing like each other. Your business is one more domain. The method transfers.

If you want to see what this operating mode looks like applied to your specific operations, your bottlenecks, your manual work, your processes that should have been automated two years ago, that is exactly the conversation worth having. You can see what this looks like inside your business.

No pressure. Just an honest look at where this would actually move the needle for you, and where it would not.

Thinking about AI for your business?

If this resonated, let's have a conversation. I do free 30-minute discovery calls where we look at your operations and find the places where AI could actually move the needle, not the hype, the real spots where you are losing hours or money to work that should be automated.

Book a Discovery Call

Get AI insights for business leaders

Practical AI strategy from someone who built the systems — not just studied them. No spam, no fluff.

Ready to automate your growth?

Book a free 30-minute strategy call with Hodgen.AI.

Book a Strategy Call