How an AI One-Person Company Actually Runs: The Split, the Lines, and the Mistakes

Table of Contents

1. Scale first, in numbers you can verify
2. The split: the top says no, the bottom finishes, only a human presses publish
3. What a day actually looks like
4. Two lines that never share a window
5. Three things never outsourced
6. Silent failure is the biggest enemy
7. Our own mistakes, listed as they happened
8. The cost, and who this is not for
9. Where to start
10. Direction

"AI one-person company" is a hot phrase right now, and most of what is written about it is vision. This post is about what it actually looks like: one person plus AI running an AI product company, how the work is split day to day, what has been handed over, what still sits with a human today, and what went wrong along the way.

We have collected the practices we published over the past few weeks into one place. Each section links to the original, and every number points somewhere you can check yourself; where something cannot be checked, it says so.

#Scale first, in numbers you can verify

We are one person plus AI, with no engineering team. The main product is MindThread, a content automation tool for Threads and Instagram; alongside it a free AI visibility check, a Claude Code handbook, and this blog.

Independently verifiable output:

• 28 pull requests merged into 15 organisations, including Microsoft, NVIDIA, NIST, OWASP and the UK Government's AI Security Institute. Every link goes to github.com, not to our own pages.
• 277 dated articles, 166 in Chinese and 111 in English (as of 21 September 2026, this one included).

One more thing that is our own statement, with no third party to confirm it: the blog has never run an ad. It sits here, outside the list above.

This is not here to boast. "One-person company" turns into a story too easily. With numbers that can be checked, the division of labour described below has some weight.

#The split: the top says no, the bottom finishes, only a human presses publish

We divide the work into two layers, plus a shipping gate kept for a human. This is the skeleton of the whole method.

The upper layer owns strategy, spec, and veto. Its job is not to get things done; it is to decide first whether something should be done and whether the spec is right. That role conflicts with construction: construction is rewarded for completion, and the shortest path to completion is accepting the premise you were given. Putting the veto outside construction is what makes "do not do this" a normal output rather than a failure.

The lower layer builds, and proves that it built. The proving takes a larger share than you would expect, often longer than the change itself.

Only a human presses publish. Not because a human is more accurate, but because shipping is irreversible, and an irreversible action needs someone who can regret it.

Right now the upper layer is Grok and the lower layer is Claude Code. Why two models, how a normal day runs, and when a human gets called are in the three-layer post. One addition here: this split cannot catch "an error both layers agree on", which is why the shipping gate stays human.

#What a day actually looks like

Nothing dramatic.

Morning starts with last night's monitors. A set of automations measures heartbeats across our services, and any "alive but doing nothing" state pushes a message. Why that matters most is a section below.

Then construction. The spec settled on the upper layer moves down; the construction line builds, verifies its own work, sends it up for review, continues if it passes, revises if it does not. No human in that loop. Only two things summon one: something is about to ship, or the construction line believes the spec is wrong. In the second case the allowed move is to say so; the disallowed move is to rewrite the spec and carry on.

At midday and mid-afternoon there are two fixed slots where one of our own Threads accounts, run by an AI agent, posts. Drafts first; a human reviews before anything goes out. How that account is governed and what the first real run exposed are in the AI employee post.

On Sundays a newsletter goes out on a schedule. It once silently skipped a week. That story is below.

#Two lines that never share a window

We have our own product, and we deliver the same product under a partner's brand. The code is one codebase; the way of working is not: two agents, two deployments, and the same window is never allowed to touch both.

The reason is two kinds of incident that are hard to notice at the time. Change A, break B: you edit a shared component on your own site, the partner site changes with it, and you never opened the partner site. Write B's words into A: you finish the partner copy, switch back to your own site, and the previous round's vocabulary is still in your head. That error produces no error message.

A real seam taught us this: one preview-only URL parameter on the main site swapped the whole homepage to the partner's brand, and the state persisted in the browser. No amount of careful copy stops a query parameter. The fix, the verification, and the cost of splitting are in the white-label isolation post. If you only have one line, do not split for an imagined second one.

#Three things never outsourced

Technically hard work I am happy to hand over. Three things I do not: shipping, external promises, breaking spec. What they share is not difficulty; it is that a mistake cannot be fixed by running again.

• Shipping: code rolls back, what others have seen does not.
• External promises: prices, deadlines and refund terms are commitments, not implementation, and the model is not bound by them.
• Breaking spec: finding a problem with the spec mid-build is normal; saying so is allowed, changing it and carrying on is not.

The full reasoning and two real self-reports are in the post on decisions not outsourced.

#Silent failure is the biggest enemy

If you remember one thing from this post, make it this one.

A one-person company lives on automation, and the most dangerous state for an automation is not crashing. It is "shows healthy, does nothing". A crash produces an error. A silent failure produces nothing at all, quietly, and you find out days later from somewhere else.

Ones we have hit ourselves:

• The weekly newsletter silently skipped a week. The log was only written on a successful send, so "not triggered" and "triggered but failed" looked identical from outside. The fix: write a heartbeat on every invocation, before deciding whether to send.
• The agent reported "1 post in 30 days"; the real figure was 61. The statistics counted only one collection. A wrong number is harder to spot than a crash, because it gets used for decisions.
• Our verification script was blocked by our own website the first time it ran. The single-page app returned a full homepage for any unknown path, HTTP 200, and that page happened to contain the string being searched for. The status code was green; the thing was wrong.

Three cases, one rule: every automation gets a heartbeat, every verification gets a positive control. The heartbeat makes "did not happen" and "failed" look different. The positive control tells you whether nothing was found because there is nothing, or because you asked wrong.

Where each case lives: the agent one is in the AI employee post; the verification-script one is written up on the handbook page; the newsletter one has not been written up yet and exists only in a commit message, so it is recorded here as is. Four more cases of the same kind are in a dedicated post.

#Our own mistakes, listed as they happened

This section is here because a post about "how we run" that only contains the parts that worked is not one you should trust.

• We put a set of platform numbers on a public page labelled "live". They were hardcoded constants; a day later they were off by ten.
• A signup form at the end of a tutorial said "in preparation" while the thing it referred to had gone on sale two weeks earlier. We effectively told a real customer "not ready yet".
• This week, drafting a post about how others collect faces, the first version said "our tools do not collect faces". Adversarial review sent it back: we have two paths of our own that touch faces. Rewritten truthfully.
• A published standards post listed five things our scanner cannot actually detect; those rules lived in a file nothing ever imported. Publicly corrected.

None of these came from technical difficulty. All of them sat in places that "looked like copy, not functionality".

#The cost, and who this is not for

The cost has to be stated.

With two layers, direction is settled above before anything moves below, so a single change is slower than doing it in one window. With two lines, cross-line work is done twice plus one handoff. The three-things rule stops work that would have been right with one more step, to ask.

Not for you if: you use AI to write things, close it when you are done, and nothing costs anything when it is wrong. None of this is needed then. It is for people who want AI to act on its own and for whom a mistake has a price.

#Where to start

If you want to try, the order is:

1. Move the veto out of construction. Not necessarily two models, but one role whose job is to say no.
2. Keep the irreversible actions for yourself. List your three; usually shipping, money, and words said in public.
3. Give every automation a signal that proves it ran. A schedule without a heartbeat does not exist.
4. Do not start by buying an "AI employee system". First make sure you can answer the seven questions before buying, then check whether what you want is an employee or a renamed tool.
5. If you work in Claude Code, we collected these disciplines into a handbook; the starter edition is free.

#Direction

Where we want to end up is humans and AI running communities together, with governance. That is a direction, not a feature that is live today. What can be said today is scheduling, publishing, replying, monitoring, and someone knowing when they break.

An AI one-person company is not handing the company to AI. It is handing over what is reversible, keeping what is not, and making sure the handed-over parts are actually running.

FAQ

Can one person plus AI really run a company?

Yes, with the scope stated plainly. Our reality is one person plus AI, no engineering team. Verifiable output includes 28 pull requests merged into 15 organisations, 277 dated articles as of 21 September 2026, and several products with public pages. What cannot be done is equally plain: shipping, external promises, and breaking spec are still done by a human today, and will not be handed over.

How many models does an AI one-person company need?

We use two layers: one for strategy, spec and veto, one for construction and proving the work is done. The reason is not that one model is too weak. It is that when the same model both proposes and builds, it will not veto itself. Putting the role that says no outside construction is what makes "do not do this" a normal output instead of a failure.

What cannot be handed to AI?

Shipping, external promises, and breaking spec. What they share is not difficulty; it is that a mistake cannot be fixed by running again. Code can be rolled back, what others have seen cannot; prices and refunds are commitments, not implementation; once the construction layer can change the spec, there is no spec.

Where does a one-person company using AI most often die?

Silent failure. A service shows as healthy but does nothing; a scheduled job did not run and produced no error; an agent reports numbers that look plausible and are wrong. We have hit a newsletter that silently skipped a week and an agent reporting 1 post in 30 days when the real figure was 61. The fix is a heartbeat and a positive control on every automation, so that "did not happen" and "failed" stop looking identical.

What is the first step if I want to start?

Separate the veto from construction, keep the irreversible actions for yourself, then give every automation a signal that proves it actually ran. Do not start by buying an "AI employee system"; first make sure you can answer the seven questions we listed elsewhere, then decide whether to buy.