single-user-factory

The reframe

The tempting model is a slider — buy safety with velocity, or the reverse. That model is wrong, and believing it makes you keep apparatus you don't need out of unease.

Most of what looked like a safety-for-velocity trade in the heavy build wasn't one. The expensive subsystems were calibrated to a specific threat model: an unattended, multi-user worker touching a production ERP, fed by a hostile intake surface. Change the threat model and they don't make you less safe — they stop guarding a danger that isn't present. That's not a point on a curve; it's the curve not applying.

The useful move is to split "safety" into three independent axes. Each one alone tells you which subsystem to keep.

"Safety" is three axes, and all three collapse for a single operator.
Axis	Drives	Company factory	Single-user
Blast radius	prevention apparatus	prod ERP for a company	I notice and fix
Reversibility	rollback & backup machinery	hard to undo prod damage	git revert, or re-run
Trust model	isolation & credential apparatus	hostile intake, untrusted worker	I feed it my own work

All three collapse toward zero, and each collapse independently deletes a subsystem. That's the whole cost saving — not accepting more risk, but building for a smaller, honest threat model.

The root fact

Content-trust is a function of authorship, not authentication. The heavy factory's content-trust floor exists because trusted people relay untrusted content — forwarded customer emails, ERP screenshots, third-party source the submitter didn't write. Narrowing who submits barely moves it.

For a single-user factory the floor nearly vanishes — not because there are fewer submitters, but because I author what I submit. That's a categorically better reason to drop it than "fewer users," and it's the reason that generalizes.

Correction worth recording: even at ETA the worker never touched the production database. Verification runs read-only against a redacted preview sandbox over HTTP; the evidence job holds no DB credential at all. The isolation architecture did the containing, not the content floor — so the floor was always more negotiable than it looked, at any scale.

What cost time, ranked

The ranking should drive what you refuse to build.

The trust-model apparatus — by far the largest. Isolation substrate, the six-requirement provider-credential lifecycle, the content floor. Entire sessions, and the current long pole. Almost all stakes-driven.
First-execution defects from horizontal slicing. Eleven of fourteen cutover-session defects were in code that had never run end to end, because the plan built by layer and nothing integrated until the end.
Live-only & silent-success defects. Code that reads correctly and behaves wrong — found only by running against real state, at the most expensive point in the pipeline. "Reports success without acting" recurred four times before it earned a rule.
Reproducibility infrastructure. GitOps-everything. What made the cutover both possible and expensive.
Governance ceremony. 114 rulings, each a PR with propagation and a metrics-regeneration gate.

Items 1, 4, and 5 are stakes-driven, not capability-driven. They don't make the factory better at resolving requests — they make it safe to run unattended, against production, at a company.

Keep at every scale

Three lessons cost nothing in safety and pay velocity at any scale. They are not on the tradeoff axis.

Vertical slices, run for real from day one. One request resolved end to end — however crude — before deepening anything. Horizontal slicing was pure loss: it deferred first execution of nearly everything to one session and produced most of the defects.
An honest failure signal. Exit nonzero when anything failed — including teardown — and say what. This gets more important as you strip everything else: with no reviewer, the run itself is the only thing that can tell you it didn't work. Both a velocity and a safety property — which is the tell that the two were never cleanly opposed.
Mutation-test your own checks. A test that passes when you break the thing it guards is worse than none — it reports coverage that doesn't exist. Mutate the source, confirm the check fails. ~Zero ceremony as a habit.

Drop or defer

Collapse the trust model → delete the isolation stack. No credential lifecycle, no capability drives, no secret-free ephemeral worker. Put the API key in the environment and run the agent directly. This deletes the current long pole outright.
Defer reproducibility. "Runs on one box I set up by hand" is fine until it isn't. Add Ansible the day you rebuild a second time — not before.
Lighter governance. A decisions.md you append to — the value (why) without the ceremony (PR + propagate + regenerate). Append-only ledgers earn their keep when a log is multi-author and cross-referenced; when you're the only one citing it, git-plus-edit is fine.
Python over Rust. Rust was justified by production, security surface, and adversarial correctness — every justification weakens at this scale. The reasons for Rust evaporate when the worst case is "my script did something dumb and I noticed." Iteration speed compounds against the real bottleneck.

The one over-correction

The failure mode of "minimal factory from a maximal one" is deleting a guardrail and the incident-detection that would tell you that you needed it back. Strip the apparatus — but keep the honest, loud failure signal. At single-user scale you have no reviewer to catch a silent failure, so the run itself has to be honest. It's the one piece of the safety story that gets more important as everything else is stripped away, because you become the only reviewer.