Anaconda published a good piece last week, "Build Your AI Dev Factory Your Way," by Brian Reed. Its argument: enterprises have bolted together models, coding assistants, data platforms and package supply chains one at a time, so proofs of concept are hard to secure, govern and reproduce. The fix is not fewer tools. It is a repeatable path, a factory, that runs Build, Test, Deliver and Operate with trust and control carried through every stage. We agree with the shape of that. Here is what a factory looks like when you are not an enterprise, and why we think RapScalYon.surf is the foundation of one.

A factory is not a prompt

The loudest version of AI development today is a person typing a request and an assistant producing an app. That is a workshop, and a good one. A factory is different: the same inputs go in, the same checks run, and what comes out has a known shape. The assistant is one machine on the line, not the line. Without the line, every app is a one-off, and every one-off carries its own login bugs, its own permission mistakes and its own unrecorded decisions.

The line, stage by stage

Anaconda's four stages map onto things that exist in our repository today. This is what is built, not a roadmap.

Build. Packs are the parts bin: 25 official, AGPL-licensed features such as item search, email sending, bot protection and WordPress sign-in, each with its own tables, security rules and tests. A stack interview asks what you are making and proposes which packs you need, and a pack-building skill produces a new pack in the shape the installer accepts. The inputs are fixed, so the output is predictable.

Test. Every pack ships a rollback and tests, and the installer validates a pack before it touches a database. Row-level security is required on every table, and access is denied by default until a policy grants it. The test runner exercises core and every pack, including removing the pack again. A pack that cannot be removed cleanly does not pass.

Deliver. Packs are versioned and applied as migrations through one installer that does a dry run first. A catalog of every pack is generated from the packs themselves, and a registry check compares a change against the main branch and fails the build if a pack changed without a version bump. Nothing hand-edits an applied migration; mistakes get a corrective migration.

Operate. Core carries what every running app needs: credits with a single charge function, a ledger of billing events, rate limiting, workspaces with members, a multi-factor gate and private file storage. Billing and sign-in can live in WordPress, with an e-commerce plugin and a sign-in plugin, so a business is not running a homemade payment system.

The foundation is the point

Anaconda's phrase is a trusted AI foundation. Ours is smaller and more literal: a secure database core that packs cannot weaken. Whatever an assistant writes on top, it cannot quietly remove row-level security from a table, because the installer will not accept the pack and the tests will not pass. That is the difference between guardrails you hope the model respects and guardrails the line enforces.

Feedback is the other half

A factory improves because production findings flow back into the line. We watched this happen with CarShopper, the used-car app we built on the framework (the full story is in our earlier post). Real use asked when a seller changed a price. We built price history for cars, noticed nothing about it was specific to cars, and moved it into the shared item-search pack as version 0.2.0, with a migration and a rollback, so the next app inherits it. The fix went down into the foundation instead of staying in one product. That is the loop.

Your factory, your way

Anaconda's closing idea is that the factory should reflect your business. We agree, and it is why the parts are packs rather than a fixed product. A restaurant, a car shopper and a real-estate lister need different parts on the same secure base. You install the ones you need, and you can remove them again.

What we are not claiming

We are not Anaconda, and this is not an enterprise AI governance suite. We do not red-team models, run a software bill of materials service or orchestrate GPUs. Our scope is the application layer for small and medium businesses and the people building for them. Nor have we shown that anyone can go from idea to live app in a day without help: CarShopper took a morning to reach live data, with Claude Code and deep knowledge of the framework, and the finishing work took longer. The line exists and it runs. It is not finished.

RapScalYon.surf is the framework and the app builder. If you would rather have a business built on it than build one yourself, RapScalYon.com is where that happens.

If you are building apps with AI assistants and each one starts from a blank page, start from the line instead. The stack interview is the front door, and the packs and installer are public at github.com/kenlyle2/rapscalyon. Source of the idea: Brian Reed, "Build Your AI Dev Factory Your Way,", Anaconda, 29 September 2026.