How one person runs eight products with an AI factory
At Next Interval, one person runs the whole portfolio. By the count in our own tracking system, that is eight active products: three software-as-a-service apps, a mobile app, a training program, a consulting service, this website, and the internal system that runs the rest. Five more are archived.
That is too much work for one person to type, and we stopped pretending otherwise. What we built instead is a small factory: a set of scheduled AI workers that take a request from a text box to a change running in production, with a person deciding at the points where a decision matters. This post describes how it works, where the person stays, and what it has done so far. We run it on ourselves first, because it is the kind of system we offer to build for other teams.
The problem is attention, not typing speed
A solo operator with eight products does not run out of ideas. They run out of attention. Every product has a backlog, a bug nobody has looked at, a dependency that needs patching, and a page that should say something clearer. Writing the code is no longer the slow part; AI tools already do much of that. The slow part is the handoffs: turning a vague ask into a spec, the spec into a change, the change into a reviewed pull request, and the pull request into production without breaking anything.
Those handoffs are the parts a team normally covers with meetings and roles. With one person, the roles still have to exist. They just do not all have to be people.
The loop
The factory is a loop of scheduled workers, each with one job.
A proposer runs at five in the morning, surveys the portfolio, and files the day's suggested work, closest to revenue first. None of it starts on its own. Each proposal waits for an explicit yes, and expires after three days without one.
Requests, whether proposed or typed in by hand, land in one request box. A triage worker checks it every fifteen minutes and does exactly one thing with each request: answers it, asks one question, turns it into a build-ready story with acceptance criteria, or declines it with a reason. Anything too big for one pull request goes to a planner, which splits it into ordered chunks that can each be reviewed on their own.
Builders pick up the ready stories, at most three at a time. Each one works in an isolated copy of the repository, hands parts of the job to sub-agents, runs the repository's own tests, and then has a separate reviewer with fresh context read the change before anything is proposed. The result is a pull request.
A principal engineer worker runs every hour. It checks what is waiting against the goal the request was filed for, releases it to production when nothing about it needs a person, watches the deployment, and reverts it if it is clearly broken.
The gates are the point
It would be easy to call this autonomous. It is not, and that is deliberate. The useful part of the design is where it stops.
Nothing starts without a person asking for it. Work the proposer suggests waits for approval; work a person types in is the ask itself. Either way, triage writes acceptance criteria before a builder touches the code.
Some changes always stop at a pull request for a person to merge. The principal engineer holds anything that touches payments, sign-in or permissions, secrets or domains, a database migration that reshapes data, or public copy on this website. This article is an example: a builder drafted it, and it went no further than a pull request until a person read it.
Some actions are never the agents' to take at all. No worker sends email or messages, publishes posts or listings, creates accounts, or spends money. When a job needs one of those, the worker writes a question on the request thread and waits.
Runaway work has a wall-clock limit. Each build run has a four-hour hard stop, holds its claim on a request through a lease it must keep renewing, and loses that claim if it goes quiet. A request that fails three times stops retrying and waits for a person. Agent sessions also record their tool-call counts and running time, so a stuck loop shows up in the numbers before it shows up anywhere else.
Questions are cheap. When a worker is unsure, it asks one question written so it can be answered cold: the goal, where things stand, what it needs, the options with their consequences, and a recommendation. Most of the human time in the factory goes into answering those, which is where it belongs.
What it has done so far
The factory is new, so these numbers are small, and they are honest. They come straight from the request records, counted when this post was written.
In its first 21 hours of taking requests, the factory received 39, 16 of them from the morning proposer. It finished 24, opened 21 pull requests, and announced 14 changes as live in production. Seven more were waiting on an answer from a person, and three were held at a pull request for review. Every one of the eight products got at least one request.
The shipped work was ordinary, which is the point: patched dependencies in one app, a week-planning feature and a household settings page in another, research and draft launch material for a new product idea, and a pass that made every page of the internal system usable on a phone.
What we take from it
The lesson is not that one person can do the work of a team. It is that the roles on a team can be written down, handed to agents, and wrapped in gates that keep the consequential decisions with a person. The approval, the stop at the pull request, the wall-clock limit, and the one-question channel are what make it reasonable to leave the workers running overnight.
That is the work we offer: find the handoffs that cost the most attention, put agents on them, and put the gates where the consequences are. If that sounds like something your team needs, talk to us.