What a software factory actually costs to build

tldr: A software factory is a pipeline where AI coding agents implement changes and humans review pull requests. The coding agent is the part you do not build. The other seven parts are the project. Ours took two engineers 23 days, with a factory that opened 7 of the 10 pull requests that built it (69 of 99).

Two engineers, 23 days, 403 commits, 17.5 of them landing every day. That is what it took to build the software factory we now sell, and the coding agent, the part everyone assumes is the hard bit, is the part we did not write at all. We use Claude Code, Codex, and Grok Build. They arrive working.

Everything else was the project. There is also a trick in that first sentence which I will come back to in the section on the bill, because 95 of those 403 commits were written by the factory itself.

I should say plainly that we now sell this as FactoryKit, which gives me an obvious interest in your conclusion. So this post is organised around the bill rather than the pitch. If the numbers make the case for building your own, that is a real answer and I have written the criteria for it at the end.

What I want to answer:

• What are the actual parts of a software factory?
• Which parts are hard, and which only look hard?
• How long before it does useful work?
• What does it cost to run, per month and per task?
• Do you need a platform team for any of this?
• When should you build it yourself anyway?

Why this is a build-or-buy question at all

Two years ago there was nothing to buy, so the best engineering teams built. That is the only reason the in-house software factory exists as a category.

Ramp built a background coding agent called Inspect, which now produces more than half of their merged pull requests, up from 30% at the start of the year. Uber built Minion, wired into their monorepo, shipping about 1,800 code changes a week with 95% of their engineers using it.

Both assigned platform teams to the problem. That is the detail that matters when you are deciding what to do on Monday. A ten person startup gets the same benefit from the software factory model that Uber does, arguably more, and has no chance of funding a platform team to build the infrastructure underneath it.

A software factory, in the sense everyone now means it, is a development pipeline where AI coding agents do the production work, implementing changes and running checks in isolated environments, while engineers direct the work and review it through pull requests. Tasks go in. Reviewed software comes out. The term is older than that and used to describe process frameworks and code generation, which is why some people now say AI software factory to be unambiguous about which meaning they intend.

The seven parts you have to build

The agent is a dependency. The factory is the seven things around it, and each one has a naive version that works in a demo and fails on contact with a real repository.

1. Isolated execution

Every task needs a fresh environment with your repositories cloned into it. Nothing the agent does can be allowed to touch anything outside that environment.

The naive version provisions a machine from scratch on every run. It works, and it is slow enough that people stop using the tool. Startup time is the difference between queueing a task casually and thinking twice about it, which decides whether the factory gets used at all.

2. Snapshot templates

This is the fix for the previous problem and it is more work than it sounds. We bake a template once per coding agent, containing the agent CLI and a browser QA toolchain, then fork it for every later run. Ours carries @playwright/cli and a bundled Chromium with its Amazon Linux system libraries, because installing a browser and its system dependencies per run is exactly the cost you are trying to avoid.

You also need a way to rotate the template deliberately, or you will be debugging a stale image at the worst possible moment. We key ours to a bootstrap hash, and bumping it forces a rebuild on the next run.

3. Credential handling

The agent should never hold a real credential. Ours does not: platform tokens are brokered into outbound requests and scoped per repository, and provider keys are encrypted at rest and injected into matching agent requests without entering the sandbox.

I want to be precise here rather than impressive, because this is where security claims usually stretch. Application environment variables that a repository needs in order to run do go into the sandbox. What stays out is our platform credentials, the model gateway keys and the GitHub tokens. "The agent cannot leak what it never had" is true of the second category and not the first, and anyone evaluating a factory should ask vendors which one they mean.

This is the station most likely to be underestimated by a team building for themselves, because the demo works fine with a token in an environment variable.

4. Git and pull request orchestration

The tempting shortcut is to let the agent run git commands. It produces tangled history and, on multi-repository tasks, one incoherent change spread across places it does not belong.

We took the other route. The agent only edits files. The platform commits the working tree, pushes a branch, and opens one pull request per changed repository through the GitHub API. Repositories the agent did not touch produce no pull request, and if nothing changed anywhere, nothing opens.

The GitHub App authentication alone, exchanging a signed JWT for an installation token per repository, is a day nobody plans for.

5. A server-owned run loop

Runs cannot depend on a browser tab staying open. If a task dies because someone closed a laptop, the factory is a toy.

This sounds obvious and it is a rewrite if you get it wrong, because it decides where run state lives from the first commit. Ours is owned by the server and persisted, so a disconnect is a display problem rather than a lost run.

6. Live observability

You need to watch a run while it happens, and you need that view to survive a reconnect. We stream the agent's narration and reasoning into a server-side buffer that the interface tails, with replay from the last event seen, so a dropped connection resumes instead of starting over or silently lying to you.

The subtler design question is what to show. Raw tool calls are noise. The narration is the log a reviewer actually reads, and choosing that took longer than building the transport.

7. Verification

Its own section, below, because it is the one everybody underestimates and the one that decides whether any of the rest is worth having.

I did not track hours per station and I will not reconstruct them now; a per-station table with confident numbers in it would be theater. The aggregate is the honest figure, two engineers and 23 days across all seven. What the git record does show is where the work kept coming back. The factory's own task history is thick with infrastructure plumbing rather than features, branch names like "login and storagestate capture feature", "when the login sandbox starts the dev server", and "sometimes tasks fail mid way with this error". The stations you build in week one are not the stations you are still debugging in week three.

Proving the change works is the expensive part

An agent can write code quickly, and the code can even be good. The question a reviewer cares about is older and harder: did this break something a user can see?

A green CI run does not answer that for user facing changes. Unit tests confirm the code does what its author believed it should. When the author is an agent that also wrote the tests, you have a closed loop that can be confidently wrong.

So we built the part that opens the loop. Before a pull request is created, the change is exercised in a real browser inside the sandbox, verified in plain language, and the session is recorded. The recording is attached to the pull request. A reviewer watches the feature work before reading a line of the diff.

We had a head start on this that most teams will not have. Our other company, Bug0, does AI regression testing for a living, and the engine is open source as Passmark, a Playwright library with caching, auto-healing, and multi-model verification of assertions. Building that from nothing, as a side quest inside a factory project, is not a few weeks of work.

What it still misses: design intent and architecture. A recording proves the button works. It does not prove the button should exist, or that the implementation behind it is one you want to maintain. Human review is still doing that job, which is the reason the pull request remains the approval gate.

The bill

The build was measured in engineer-months. The surprise was that running the factory is cheap and reviewing its output is not.

Three numbers that should never be blended into one.

Build cost. Two engineers, 23 days, 403 commits. That is the FactoryKit repository from its first commit on 9 July 2026 to 31 July 2026, and it is the whole of what you see described above. Call it roughly 1.5 engineer-months of calendar time, with the caveat that the two people involved had built adjacent infrastructure before and were not learning the problem from scratch. The answer to how long before it does useful work sits inside that window: the first pull request ever merged into the repository was the factory's own, 5 days after the initial commit, and it closed its first full week with 21 of them.

The number that makes that possible is the one in the next line, so I want to be careful not to smuggle it past you. Of the 403 commits, 95 were written by the factory, and of the 99 pull requests merged in that window, 69 came from the factory itself. What those pull requests were, which merged untouched, and where the agents failed is the subject of agentic coding vs vibe coding. The build cost above is what it takes to build a software factory when a software factory is doing a large share of the work. Starting cold, without that compounding, I would plan for materially more. For contrast, Ramp and Uber funded standing platform teams to build and run theirs; our entire bill was the 1.5 engineer-months above, caveats attached.

Running cost. I am not going to put a monthly invoice figure here, because I have not reconciled a clean month and a cost number that might be wrong is worse than none. The structure is worth more than the total anyway. The marginal cost of a task is model tokens plus sandbox minutes, both metered, both billed as they are used. The fixed cost underneath is storage for the QA recordings, a database for run state, and hosting for the app, and for us those have been a rounding error next to model spend. The budgeting consequence is the useful part: a factory's running cost scales with how many tasks you queue, not with how many engineers you employ, which is the reverse of how engineering costs usually behave. The line that grew fastest for us is on no invoice at all: review attention, which scales with every merged pull request and lands on your most senior people.

Maintenance. This is the line item nobody budgets. Agent CLIs update, models get deprecated, sandbox images drift, and a provider changes something on a Tuesday. An internal software factory is a product with exactly one customer, and somebody owns it for as long as the company uses it. That somebody is a person on your team, forever, and their name is usually decided by accident.

Station	Does a buyer inherit it?
Isolated execution	Yes
Snapshot templates	Yes
Credential handling	Yes
Git and PR orchestration	Yes
Server-owned run loop	Yes
Live observability	Yes
Verification	Only if the vendor has it

That last row is the one to press vendors on. Most of the category ships the first six and stops, because the seventh requires a browser automation and regression testing capability that has nothing to do with language models.

Build or buy is the wrong question

Almost every reason a team gives me for building in-house is a reason about their environment, not about the factory. Environments are the one thing a vendor can come and solve inside your walls.

The reasons I hear are consistent. Our monorepo has tooling nobody outside the company has seen. Our code cannot leave infrastructure we control. Our stack is not what these products are built for. Every one of those is real, and none of them is an argument that the seven stations should be built again from scratch by your platform team.

They are arguments that somebody has to do the last mile of work inside your environment. That is a staffing question, and it has a different answer than build or buy.

Ours is forward-deployed engineers. Our engineers install the factory inside your infrastructure, run it on your own backlog for the first 1 to 3 months, and hand it over to your team. The engagement ends with you owning a working software factory and the people who know how to run it, rather than a license and an onboarding deck.

The distinction that matters for the bill: your platform team does not build the seven stations, and it does not inherit the maintenance line item either. The stations already exist, and after handover they stay maintained under the subscription rather than becoming somebody's second job. What gets built during the engagement is the part that is specific to you, the integrations and the environment work, and it gets built by people who have stood the same thing up before. Self-hosting, on-premise, and air-gapped deployments happen this way too, in case you have been told that only the largest vendors can run inside your network.

I am describing our own commercial model, so weigh it accordingly. The reason I think it is the right shape rather than a convenient one is in the numbers earlier in this post. We built the seven stations once, with two engineers, and we were the people who had already built adjacent infrastructure and had a factory helping. A team doing it cold, as a side project next to a product roadmap, is signing up for something considerably larger.

When you should still build it yourself

If you are Ramp or Uber, build. Below that scale the honest case for building is narrow, and it is about control rather than capability.

Build if a vendor inside your environment is itself the problem, which is a real answer in some regulated and defence contexts. Build if you already fund a platform team whose roadmap this genuinely fits, and who will still be staffed to own it in two years. Build if the factory is going to become part of what you sell, in which case you are not buying a tool, you are entering the same business we did.

Otherwise the calculus is the one every engineering organisation already knows from CI. Almost nobody writes their own CI system now, and the teams that still do have a specific reason they can name in one sentence.

The honest limits of the bought option, ours included: web applications are the sweet spot and mobile is not supported, we are GitHub only for now, and a vague task still produces a vague pull request no matter how good the infrastructure underneath it is. An engagement does not change the first two. It changes who does the work of fitting the rest to your environment.

What I would tell my own team, if we were making this decision again: spend a week building a prototype, purely to learn what the stations are and why the seventh is hard. Then decide, with the prototype as a reference point rather than a head start. The mistake is to read the prototype as the distance remaining, because the first six stations are perhaps a third of the work and the seventh is most of what makes the output trustworthy.

The same engine, built for you

If the seven stations read like a system you want without the project of building it, that is the business we are in. FactoryKit is the engine this post described, and the enterprise motion is the one from the middle of the post: forward-deployed engineers stand the factory up inside your infrastructure, run it on your own backlog for the first 1 to 3 months, and hand it over, with the maintenance staying on us under the subscription. Self-serve on our cloud exists too, if you would rather try it on one repository first.

Book a demo, or start at factorykit.ai.

FAQs

What is a software factory?

A software factory is a development pipeline where AI coding agents implement, check, and test changes in isolated environments while engineers direct the work and review it through pull requests. Tasks go in and reviewed software comes out. The term once described process frameworks and code generation, and now describes what Ramp and Uber built internally.

What is software factory as a service?

Software factory as a service means buying that pipeline rather than building it: a vendor runs the sandboxes, credential brokering, agent orchestration, verification, and pull request workflow, and you connect your repositories. It is the alternative to funding a platform team to build the same seven components in-house.

How much does it cost to build a software factory?

Two engineers and 23 days, roughly 1.5 engineer-months, with a factory helping build itself and the coding agent excluded because we use existing ones. Starting cold, plan for materially more. The larger ongoing costs are maintenance and review attention, and the most expensive component to build is verification.

Should we build or buy a software factory?

Neither, in most cases. Unusual tooling and data residency rules are environment problems rather than reasons to rebuild the pipeline, and they can be solved by a vendor working inside your infrastructure. Build only if having a vendor in your environment is itself the problem, or if the factory becomes part of what you sell.

Do we need a platform team to run a software factory?

No, and that is the main reason the in-house route is expensive. In a forward-deployed engagement the vendor's engineers install the factory in your infrastructure, run it against your backlog for the first 1 to 3 months, and hand it over. Your platform team neither builds the seven components nor maintains them.

What is a forward-deployed engineer in this context?

A forward-deployed engineer works inside your environment rather than on the vendor's core product, doing the last mile: integrations, environment fit, and adapting the factory to how your team actually works. For software factories it is what replaces the platform-team project, since the pipeline itself already exists.

What software factory tools do you need to build one?

The software factory tools you assemble are a sandbox provider for isolated execution, a coding agent CLI, a git host API for branch and pull request creation, a durable store for run state, an event stream for live observability, and browser automation for verification. The agent is the only part you can treat as an off-the-shelf dependency.

How is a software factory different from CI/CD?

CI/CD runs checks against changes a human already wrote. A software factory produces the change as well: an agent implements the task, runs those same checks, verifies the result, and opens the pull request. The factory sits before CI in the pipeline and does not replace it.

Who has built a software factory in-house?

Ramp built Inspect, now behind more than half of their merged pull requests. Uber built Minion, shipping about 1,800 code changes a week. Defence programs have run software factories under that name for years, though in the older process-framework sense of the term.