Case study / 02
MiniMindsLab Software Factory
A browser-tool production line that turns small software ideas and legacy utilities into tested, canonical static tools through frozen specs, bounded repair, deterministic QA, browser verification, and controlled deployment.
The problem
Small browser utilities are easy to prototype and surprisingly hard to operate as a growing catalog. Each tool can arrive with different assumptions, dependencies, UI patterns, failure modes, and deployment requirements. Manual cleanup works for a few tools, but it does not create a repeatable software operation.
The factory
MiniMindsLab separates the work into explicit stages: intake and deduplication, frozen tool specification, Codex-assisted implementation, deterministic build QA, targeted repair, browser QA, canonical commit, site build, deploy, and live verification. A tool cannot become canonical simply because it renders; it has to satisfy the contract created upstream.
What the failures exposed
Real migrations forced the factory to confront issues that simple unit tests missed: incorrect per-type numbering, opacity values lost at zero, asynchronous overlay state races, rotation bounds, CSV escaping, and browser locator behavior. The Regex Extractor exhausted its bounded repair attempts and was stopped rather than being pushed live.
The correction pattern
Repairs are made at the narrowest responsible layer. Tool-specific implementation defects stay in the repair loop, while recurring factory defects are corrected in shared QA or build logic. Canonical source remains separate from staging and public deployment, so failed experiments do not silently mutate production.
What it demonstrates
The result is less a collection of web pages than a small software factory: source artifacts enter through a controlled contract, failures leave evidence, repair is bounded, and only exact QA-approved builds are allowed to advance. The same machinery can keep producing tools without turning every new utility into a bespoke deployment project.