When I say "software factory," I do not mean a prompt that spits out a homepage. I mean a repeatable path from an idea to a site that can stand on its own, and a way to change it again without quietly losing the things people entrusted to it.

We now have two useful examples in front of us. The Antsand blog talks about building software and running a small company. ShivasNotes is where I write deeper technical material and build out accounts, protected reading, comments, audio, and commerce. They should not have the same voice or the same member data. But I also do not want two unrelated teams of templates, navigation, CSS, and deployment scripts.

What goes through the factory?

There are three inputs I keep separate. Notes holds the authored article. Databoard, our internal site-composition tool, decides which pages, sections, bindings, and routes belong to a particular site. Shared source supplies the templates, HMVC behavior, and styling that make those choices work. The generated site gets its own files and runtime.

That distinction matters on an ordinary Tuesday. Fixing an article typo should not require me to rebuild an account system. Changing a route or an authorization rule does require more than copying a JSON file. If the path through the factory is explicit, I can tell which kind of change I am making and what needs to be tested.

"Reusable" should mean I can improve the machinery once. It should not mean one site accidentally inherits another site's readers.

Same machinery, different ownership

The two websites can use the same article renderer and design components. The decisions about what to show are still site-specific. A public Antsand article is not automatically a ShivasNotes member article. A ShivasNotes purchase is not an Antsand blog subscription. Even when the records use a similar schema, they must remain scoped to the right site.

The Antsand blog is the clearer publishing example. Our generated blog has its own application and content cache; it does not need the Notes editor to render each public page. ShivasNotes has more local state. Its generated site includes a SQLite database for member and commerce workflows. That makes the rule sharper: when code is regenerated, accounts, comments, entitlements, and uploaded assets cannot be treated as temporary output.

I also do not want to overstate "independent." A generated page can render from local code and cached data, but authoring, syncing, email delivery, payments, and operations have their own dependencies. The point is to draw those dependencies honestly rather than pretend a folder of PHP has no outside world.

Why the second site is the real test

A single website can hide a lot of hardcoding. A second one exposes it quickly. Is /books a sensible destination everywhere? Is the same menu supposed to appear for a guest and a signed-in member? Does a shared stylesheet still look right when the brand colors change? Can an administrator in one group see the other group's data? These are better questions than "Can the generator make another homepage?"

Some choices should stay shared. If you bought a non-consumable ebook outright, the server should not charge that account again just because the checkout button was reached by a different route. Other choices belong in the site's configuration: whether a book is included with membership, which route opens it, and which sections appear in navigation. The factory gets stronger when we can tell those apart.

What we can actually show

Both public homepages responded when I checked them while preparing this article. Shared generation and data-sync code exists, and the local generated ShivasNotes deployment has a site database. That is useful evidence for the architecture. It is not proof that every production restore, payment lifecycle, or release gate has passed.

What an AI agent can do here, and what it cannot certify

I use agents to investigate a bug, prepare a patch, write a test, and sometimes help shape an article like this. That is useful leverage. It is not a reason to skip review. A passing source test does not tell me that a generated page looks right on a phone. A successful purchase test does not prove that a failed renewal recovers correctly. A site that loaded once does not prove that restoring yesterday's backup will preserve today's comments.

So I want the factory to produce more than files. For a consequential change, I want a source revision, a generated revision, the scenarios actually run, a clear list of what was skipped, and a rollback path. If checkout is not ready, we can publish an article without enabling checkout. If a generated site has not been exercised, the status should say unverified, not "75% online."

What I want to build next

This is the beginning of a series, not a victory lap. I want to show how one article moves from Notes into a generated blog, how a design component travels from shared source into two brands, and how we test regeneration with real local state already present. I also want to show the less glamorous parts: a failed sync that keeps the last good content, a member who must not lose access, and a status board that says what it actually knows.

That is the version of a software factory I find interesting. The machine can repeat the work. We still decide what deserves to ship, what belongs to each site, and what evidence makes us trust the result.