What a software factory actually costs to build

tldr: A software factory is a pipeline where AI coding agents implement changes and people review the pull requests. The coding agent is the part you don't build. The seven parts around it are the project. That cost is the reason Buildful exists: spread across many people, the same machinery comes to about a cent a task.

This post first described FactoryKit. FactoryKit is now Buildful, and this version is updated for what it does today (October 2026).

When we built FactoryKit, the software factory that later became Buildful, the coding agent was the part we didn't write at all. It's the part everyone assumes is hard. In July we used Claude Code, Codex and Grok Build, and they arrived working.

Everything else was the project. This post is about what that took, part by part, and what it costs to keep running. Buildful is what we did with ours, so read the last section with that in mind.

What a software factory is, and why people build them

A software factory, in the sense people mean in 2026, is a development pipeline where AI coding agents do the production work, implementing changes and running checks in isolated environments, while people direct the work and review it through pull requests. The term is older and once described process frameworks and code generation, so some people say "AI software factory" to be clear about which one they mean.

Ramp and Uber both built one for their own engineers, and I covered how they run them in another post. What counts here is that they built it with their own engineers. The software factory model works as well for a ten-person startup or a freelancer as it does for Uber. The difference is that a ten-person startup can't spare engineers for months, and a freelancer can't spare anyone.

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 a real repository.

1. Isolated execution

Every task needs a fresh environment with your repositories cloned into it, and nothing the agent does can reach outside it.

The naive version sets up a machine from scratch on every run. It works, and it's slow enough that people stop using it. Startup time decides whether someone queues a task casually or thinks twice, and that decides whether the factory gets used at all.

2. Snapshot templates

This is the fix for slow startup, and it's more work than it sounds. We build a template once per agent toolchain, shared by every model, repo and team, then fork it for each run. In July ours carried @playwright/cli and a bundled Chromium with its Amazon Linux system libraries, because installing a browser and its system dependencies on every run is exactly the cost you're trying to avoid. Today it also carries a second browser tool for the recorded test run and ffmpeg to encode the recording.

You also need a way to rebuild the template on purpose, or you'll be debugging a stale image at the worst moment. We key ours to a bootstrap hash, and bumping it forces a rebuild on the next run. Any change to an agent CLI or the browser toolchain means a bump. We've done that more times than I expected.

3. Credential handling

The first version of this post said our credentials never enter the sandbox. That's true of some credentials and not others, and the difference is the whole point of this station.

Our own keys, the model gateway key, the GitHub tokens and the storage credentials, never go in. The sandbox firewall adds them to requests as they leave, so the agent CLI only ever holds a placeholder. If you bring your own model API key, it's encrypted at rest and added to model requests the same way.

Your repository's environment variables do go in, because your app has to run for its checks and its browser test to mean anything. We encrypt them at rest and show them masked, and we tell people to use staging or development credentials only. Prompts carry the names of environment variables, never their values, because prompts get logged.

This is the station a team building for itself is most likely to skip, 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. It produces tangled history and, on multi-repo tasks, one incoherent change spread across places it doesn't belong.

We went the other way. The agent only edits files. The host commits the working tree, pushes a branch with --force-with-lease, and opens one pull request per changed repository through the GitHub API. Repos the agent didn't touch get no pull request, and if nothing changed anywhere, nothing opens. A follow-up on the same task adds commits to the same pull request.

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

5. A run loop that doesn't need you

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

We got this half right at first. Runs were owned by the server from day one, so a disconnect was a display problem. But the agent's turn ran inside a serverless function, and functions have time limits. Early on we kept raising the function's time limit. That bought time and fixed nothing. On September 30 we moved the turn into the sandbox itself: a small tailer in the VM follows the agent's event file and posts new lines back to the server, and the request that sees the turn end does the shipping. A turn now runs until the agent finishes, goes quiet for 15 minutes, or the sandbox's 2 hours run out.

Where run state lives and where the work runs get decided early, and changing either later is a rewrite. We did that rewrite two months after launch.

6. Live observability

You need to watch a run while it happens, and the view has to survive a reconnect. We stream the agent's narration and reasoning into a server-side log that the interface tails, with replay from the last event seen, so a dropped connection picks up where it left off.

The transport has traps. On September 29 we measured a sandbox command's log stream closing cleanly 340 and 520 seconds into a silence while the command kept running. Treat that as the end of the transcript and you ship half a run. So the agent CLIs we wrap ourselves run with a heartbeat line and a copy of their event log on disk, we replay any lines the live stream missed after it exits, and the turn fails if the stream never reached the CLI's final event.

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

7. Verification

This gets its own section below, because it's the one everybody underestimates.

I didn't track hours per station, so I won't put a figure on each one. What I can tell you is where the work kept coming back. Our task list from those first weeks is full of plumbing, with 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 aren't the ones you're 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. A reviewer wants to know something harder: did this break anything a user can see?

A green CI run doesn't answer that for a change people will see. Unit tests confirm the code does what its author believed it should. When the author is an agent that also wrote the tests, that loop can be confidently wrong.

So we built two steps that open the loop. First, the repo's own checks run, and if one fails, the agent fixes it and runs it again, up to 3 attempts, before it reviews its own diff. Second, for any change with a UI, the agent starts the app in the sandbox and uses the changed feature end to end in a real browser while the session is recorded. It has to click and type the way a person would. Checking the result by calling the app's own API doesn't count. The recording goes into the pull request as a GIF, with the full video kept privately, and a reviewer can watch the feature work before reading a line of the diff.

Each part has a failure you only find on real repos. An app missing its environment variables won't start, and the agent has to say so instead of claiming a test it didn't run. Many features sit behind a login, so each repo can store a captured login and the test starts signed in. And left alone, an agent will record a smoke test that only opens the page.

We had a head start: our other company, Bug0, does AI QA for a living. Building this from nothing, as a side quest inside a factory project, takes far more than a few weeks.

What it still misses is design intent. A recording proves the button works. It doesn't prove the button should exist, or that the code behind it is something you want to maintain. That's still the human reviewer's job, which is why the pull request stays the approval gate.

The bill

People ask about the cost of building it. For us, running it turned out cheap, and reviewing its output didn't. Those are three different costs, and blending them into one number hides the one that grows.

Build cost. The first working version came together faster than I expected, and I'd discount that for two reasons. We'd built similar infrastructure before, so we weren't learning the problem from scratch. And once the basic loop worked, we used the agent to build the rest of the tool, through the same pull requests and review it now gives everyone else. That's a head start nobody has on day one. What the agent got right and where it needed us is in agentic coding vs vibe coding. Starting cold, without either advantage, plan for a real project: engineers who own it for months, and the seventh station taking longer than the other six.

Running cost. I'm not putting a monthly invoice here, because I haven't reconciled a clean month and a wrong number is worse than none. The cost of one more task is model tokens plus sandbox minutes, both billed as they're used. Underneath sit storage for the recordings, a database for run state and hosting for the app, and for us those have been small next to model spend. So the running cost grows with how many tasks you queue, not with how many people you employ. The line that grew fastest is on no invoice at all: review attention, which grows with every merged pull request and lands on your most senior people.

Maintenance. Nobody budgets this line. Agent CLIs update, models get deprecated, sandbox images drift, and a provider changes something on a Tuesday. We pin one agent's bridge to an exact version and carry a patch for it; one change in that patch exists only so a "Reconnecting..." notice from the CLI stops failing the whole turn. Every CLI change means a template rebuild. The log stream that closes on a silence was a September discovery, two months after launch. An internal software factory is a product with exactly one customer, and somebody on your team owns it for as long as you use it.

When you should still build it yourself

If you have engineers to spare and someone to own it for years, build. Otherwise the case for building is narrow, and it comes down to control.

Build if having an outside service in your environment is itself the problem, which is a real answer in some regulated settings. Build if you already pay a platform team whose roadmap this fits, and who'll still be there to own it in two years. Build if the factory will become part of what you sell, because then you're entering the same business we did.

Otherwise it looks a lot like CI. Almost nobody writes their own CI system now, and the teams that do can name their reason in one sentence.

What I'd tell my own team if we were deciding again: spend a week on a prototype, purely to learn what the stations are and why the seventh is hard. Then decide, and treat the prototype as a reference point. The mistake is to read the prototype as most of the distance. The first six stations are maybe a third of the work, and the seventh is most of what makes the output worth merging.

What we did with ours

In July we were selling FactoryKit to engineering teams, with demos, forward-deployed engineers and self-hosting. The costs above show the problem with that plan. The seven stations and their maintenance get paid for once, whoever uses them, and what grows with each task is tokens and sandbox minutes. A few large customers would leave most of that machinery idle, and it costs about the same to run for a handful of people as for thousands.

Meanwhile the people who most need a background coding agent can't pay for engineers or a \(200-a-month AI plan: students, freelancers and people building on their own, many in India and other places where \)20 a month is real money.

So we rebuilt it around tasks. You describe a change and get a tested pull request on your GitHub repo, and 1,000 tasks cost $10 a month. Tokens are most of the cost of a task, so the model is where the price gets decided. Buildful reads each task and picks the right open-weight model for it: a fast one for a small fix, the most capable one, with more time to think, for a hard task. Open-weight models cost far less per token than frontier models, and that's what lets the price work. If you want a frontier model for a task, you can pick one yourself on the paid plans, with prepaid credit or your own API key.

The seven stations above are all still there. Every change runs your checks, every UI change is tested in a real browser and recorded, and the agent still never runs git. If you'd rather use them than build them, they're at buildful.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 people direct the work and review it through pull requests. The term once described process frameworks and code generation.

What is software factory as a service?

Software factory as a service means using that pipeline instead of building it: someone else runs the sandboxes, credential handling, agent loop, verification and pull request workflow, and you connect your repositories. It's the alternative to putting your own engineers on the same seven parts for months.

How much does it cost to build a software factory?

The coding agent is bought in. The cost is the seven parts around it: isolated execution, snapshot templates, credential handling, pull request orchestration, a run loop, live observability and verification. Verification is the most expensive to build, and the bigger ongoing costs are maintenance and review time. Plan for engineers who own it for as long as you use it.

Should you build or buy a software factory?

Build if you have engineers to spare and someone to own it for years, if an outside service in your environment is itself the problem, or if the factory becomes part of what you sell. Otherwise, use one someone else maintains.

How is a software factory different from CI/CD?

CI/CD runs checks against changes a person already wrote. A software factory produces the change too: an agent implements the task, runs those same checks, verifies the result and opens the pull request. It sits in front of CI and doesn't replace it.