What is a software factory?

Hitachi opened the first named software factory in 1969, and the idea has cycled through the industry ever since (the Wikipedia entry traces the lineage). Every revival kept the same premise: software gets cheaper and more reliable when you standardize how it is produced instead of treating each project as a craft piece.

The second era was institutional. Microsoft published a methodology under the name in 2004, and the US Department of Defense stood up dozens of software factories, Kessel Run and the Army Software Factory among them: shared platforms, shared pipelines, software shipped at a predictable cadence inside organizations not known for either.

The third era is the current one. Engineering organizations started wiring coding agents into production lines. Ramp’s background agent now accounts for more than half of the company’s merged pull requests. Uber’s internal agents ship around 1,800 changes a week. Neither company uses the phrase. That is what a software factory is.

DevOps automates the path to production for code humans write: CI, CD, infrastructure as code, observability. A software factory starts one station earlier and automates part of the writing itself. DevOps is a culture and a toolchain. A factory is a system with intake, production, inspection, and output.

The cleanest test: DevOps makes each engineer faster, while a factory produces changes whether or not an engineer is at a keyboard. If your pipeline waits for a human to open the pull request, you have DevOps. If the pull request arrives on its own, checks passed and evidence attached, you have a factory.

The functioning software factories we know of, internal or commercial, converge on the same five stations:

• Intake. Work arrives as a task with acceptance criteria: a ticket, a Linear label, a typed request. Not a chat prompt.
• Implementation. A coding agent works the task in an isolated sandbox, with scoped credentials and no access beyond its own repos.
• Checks. The repo’s own lint, build, and tests run on every change, with a budget of fix attempts before a human ever sees it.
• QA. UI changes get exercised in a real browser, and the session is recorded as evidence.
• Output. One pull request per changed repo. The PR is the approval gate; humans review and merge.

The station most teams skip is inspection. Manufacturing settled this a century ago: you do not scale output without scaling QA. The same rule holds for code, which is why we treat verification as part of the product rather than a stage after it (the agentic SDLC makes that argument in full).

Ramp and Uber built theirs in-house, with platform teams and months of engineering. That is the build path, and at their scale it can be worth it. The buy path is newer: install a factory instead of building one.

FactoryKit is the buy path: our forward-deployed engineers set the factory up on your own infrastructure, wire it into your repos and your tracker, run it against your backlog for the first 1 to 3 months, then hand you the keys. Or start self-serve at $99 per user per month plus pay-as-you-go model usage (how both plans work).