Built from operational work, not a clean-sheet theory.
Buildfactory grew from infrastructure automation into controlled AI-assisted delivery by extending a working base whenever real projects exposed another problem that needed to be controlled.
One line of work became a delivery system.
Buildfactory did not begin as a feature matrix. It grew as deployment, repair, configuration, and later AI-assisted work demanded more reliable ways to make, verify, and recover changes.
- 01 / INFRASTRUCTURE
It began with infrastructure automation.
Server deployment, upgrades, repair, and configuration, built with Ansible and shell scripts.
- 02 / EXTENSION
LLM automation entered an existing operational discipline.
The same environment already needed bounded execution, repeatability, repair, configuration control, and proof that work had actually completed.
- 03 / REUSE
Features came from real projects.
The working folder was copied into project after project. Each new failure mode, repeated manual task, or unsafe handoff led to another script, worker, procedure, gate, or remediation route.
- 04 / CENTRALISATION
The factory became centralised.
Once multiple projects needed the same delivery machinery, Buildfactory became the management layer for coordinating them rather than a folder of useful scripts.
- THE OPERATING BASE
- 05 / SHAPE
Why it can look ad hoc at first.
It did not begin as a polished framework designed around a feature matrix. It grew around actual constraints. To a first-time reader, it can look like many specialised pieces; to a team operating it, those pieces remove specific recurring problems and fit together as one delivery system.
- 06 / DISCIPLINE
The strict starting context shaped the system.
Its earliest operating mode demanded very high assurance: infrastructure changes, repairs, upgrades, and configuration can have serious consequences. That is why strict specification, test obligations, isolated sandboxes, controlled execution, recovery, and evidence are foundational—not enterprise add-ons.
- 07 / PRESENT
It continues to grow with AI-assisted development.
The same pattern continues: new AI failure modes become explicit controls, rather than forcing developers to babysit them manually.
FOUNDER + ARCHITECT
Kerry Panchoo builds systems where AI judgment has to work alongside engineering control.
Kerry is the Founder and President of Sarolta Technologies and Buildfactory’s Principal AI Systems Architect. He has built software products, infrastructure platforms, automation systems, and AI applications across his career—not simply assembled a tool around the current wave of coding agents.
He holds MSc degrees in Expert Systems Engineering from the University of Sheffield and Evolutionary and Adaptive Systems from the University of Sussex. That background in symbolic and neural AI shapes Buildfactory’s central idea: use models where judgment is useful, and use deterministic controls where a system needs to be repeatable, inspectable, and safe to operate.
Sarolta TechnologiesPrincipal AI Systems Architect
BuildfactoryTwo MSc degrees
Artificial Intelligence
Evaluate the machinery against a real delivery problem.
Use a representative repository and ask your own engineers to inspect the workers, controls, procedures, evidence, and operating boundaries relevant to your work.