We built an AI product factory. Here’s what worked, what broke, and what comes next.

The question

I’m interested in useful businesses that never get built because the opportunity looks too small to justify the work. Nullfield asks what becomes worth trying when we can reduce the work required to build and operate a company.

V0 focused on a smaller question: could the Factory carry a simple idea from a brief to a working page, with a clear record of the decisions in between? We used three deliberately basic test cases: Game Night Ready, Tank Start, and Sprout Start.

We recorded the order before we began and ran the products one at a time. These were tests of the Factory, not bets on customer demand.

Three basic businesses

Game Night Ready is a bold, dark poster for first-time board-game hosts. Tank Start is an ice-blue checklist for new aquarium owners. Sprout Start is a quieter, cream-and-green page for balcony herb growers. Each offers three simple prompts and a button that takes you to the guidance already on the page.

We kept each business intentionally basic. Each one is a static guide with three useful prompts and one button. There are no accounts, databases, recommendation engines, or other product logic. That was enough to test whether the Factory could turn a brief into something real and publish it privately.

The first Game Night run exposed a limitation: every product used the same layout. We added three fixed templates and ran Game Night again. The portfolio shows the final set. The earlier run remains in the internal history and cost ledger.

Each final product contains 14 verified source files. The screenshots below show the pages exactly as the Factory produced them.

What v0 actually proved

The result was not simply three screenshots. Each page can be traced back to an approved brief, verified source code, and a recorded release decision. That traceability is the core proof from v0.

Every product followed the same seven steps: define the product, approve the brief, build the page, verify the source, approve the release, publish the test, and decide what should happen next. Each approval was attached to a specific artifact, so the thing we reviewed was the thing the Factory used.

I set the boundaries for the experiment and authorized Codex to complete the routine reviews within them. That delegation did not remove the controls. The Factory still recorded what was approved, what failed, and what was ultimately published.

Why the dashboard mattered

Once we had several runs, the Products dashboard became the clearest way to understand the Factory. It shows each product, its current state, the seven steps behind it, and whether its infrastructure still matches the recorded status.

The public portfolio shows three finished examples. The dashboard shows the current state of the wider product catalogue, including retired products whose infrastructure is gone. The deeper record of earlier workflows, failures, and retries lives in the preserved evidence rather than the dashboard itself.

What breaking taught us

Game Night and Tank both failed during source creation after their briefs had been approved. AWS denied the operation that would create the source commit. The records show exactly where they stopped, but not why the permission check failed.

We resumed each product from its approved checkpoint instead of starting over. The specifications stayed the same, both products finished successfully, and the failed attempts remained in the history and cost ledger. Sprout completed its main run without a failed agent attempt.

The clearest lesson was simple: recovery only means something when the record includes both the failure and the successful result. A clean final screenshot is not enough.

Proving we could finish cleanly

Creating a product was only half the test. We also needed to know that the Factory could remove its infrastructure without losing the evidence required to understand what happened.

Before retiring each product, we saved its screenshot, exact source, and history. Retirement required separate approval. We then removed the test page and source repository, confirmed both were gone, and verified that the product remained visible in the dashboard. All three v0 products are now retired.

What v0 did not prove

V0 proved a bounded production process. It did not prove that these ideas should become businesses. Three completed examples do not establish customer demand, statistical reliability, autonomous operation, or the economics of running a company.

The model costs were small, but they are only one part of the cost. The missing AWS, shared-development, and human-time measurements matter more than another decimal place in the model subtotal.

The closeout produced another useful lesson: more review steps do not automatically create more confidence. Our first audit became too large and still produced bad references. We preserved that work, simplified the process, and used one independent reviewer to check the final evidence.

What changes in v1

V0 gives us a controlled way to build, inspect, recover, and retire a simple product. V1 carries those controls forward.

The next version starts with original needs, gives each product a distinct identity and logo, publishes it on its own .com, and measures real demand. That is the point where the Factory begins testing businesses, not only its own machinery.