Should a small startup build a software factory?

The idea is not hype. BCG Platinion describes organisations running this model reporting productivity gains of three to five times, and OpenAI has described building an internal product from an empty repository with three engineers steering coding agents and no hand-written code, including tests, CI, documentation and observability.

So the question is not whether it works. It is what it does to a company that has no CTO and three contractors.

What is a software factory?#

A system that takes signals in one end and deployed software out the other.

Bug reports, specifications, customer feedback go in. Fleets of coding agents write, test, review and ship. People define what should be true and check the results. The loop runs continuously rather than waiting for a person to pass work along.

That is the whole idea. Notice what it assumes.

What it assumes, and why that matters more than the tooling#

Read the definition again. It assumes three things exist already.

Somebody can define intent precisely. Agents do what they are told. A vague instruction produces confident, working, wrong software, faster than before.

There is an automatic way to know the output is acceptable. Tests, checks, an evaluation set. Without them, "verified software out the other end" is just software out the other end.

Somebody reviews. Not reads every line. Decides what is acceptable, and can tell when it is not.

A large engineering organisation has all three, imperfectly. That is why the multiplier works there. It multiplies discipline, and a company with none gets none multiplied.

What happens when a small startup skips to the agents#

Three failures, in the order they arrive.

Month one feels extraordinary. Volume goes up dramatically. Features appear. This is real and it is the part everybody reports.

Month three, nobody can change anything safely. There is now several times more code than a person has read. No test suite grew alongside it, because nobody asked for one. Every change carries unknown risk, so changes slow down, which is the opposite of what was bought.

Month six, the only person who understands it is the agent, and it does not remember. This is the failure that has no cheap fix. A codebase nobody understands still runs today and cannot be improved, and "we need to rewrite it" is eighteen months away.

None of that is a reason to avoid coding agents. It is a reason to build the checking before the volume.

What to build first, in order#

The factory is the loop, not the agents. Build the loop.

1. Somewhere the work is visible. A link you can open that shows the current state. If progress is only visible when somebody shows you, you cannot supervise a factory or a contractor.

2. Automatic checks on the journeys that make money. Not full coverage. The two or three paths where a break costs you customers. This is the single highest-value thing on this list and it is usually absent.

3. Ownership in your name. The repository, the hosting, the domain. Multiplying output into an account somebody else controls multiplies your exposure too.

4. A written definition of acceptable. For each significant piece: what must be true for this to be finished. This is the thing agents need and the thing nobody writes down.

5. Then agents. At this point they compound something. Before it, they compound nothing.

Steps one to four cost days, not quarters. Most small companies are missing two or three of them, and you can check which in about an afternoon.

The honest version of the productivity claim#

Three to five times is reported by organisations that already had the loop. Read it as a multiplier on existing discipline rather than a substitute for it.

And note what the OpenAI example actually contains: tests, CI configuration, documentation, observability. The output was not a million lines of application code. It was a working system with its checking apparatus included, steered by three engineers who knew what acceptable looked like.

That last clause is the expensive part, and it is not something a tool provides.

When the answer is yes#

Three cases where a small company genuinely should do this now.

Your team already has tests and review, and output is the bottleneck. Then it is straightforward, and you should move.

The work is genuinely repetitive. Fifty similar integrations, a large migration, hundreds of similar pages. Repetitive work suits agents better than anything and the acceptance criteria are easy to write.

You have somebody technical who can define acceptable and check it. Full-time or not. This is the real prerequisite, and it is why the answer is often not a tool at all.

What to do this week#

Pick the two journeys in your product where a break would cost you a customer. Ask whoever builds your software whether there is an automatic check on each. Ask to be shown it running.

If the answer is no, that is your first project, and it is a week rather than a quarter. If the answer is yes, you have the beginnings of a factory and adding agents will compound it.

If nobody in the company can judge the answer, that is the finding, and it is the case for somebody technical rather than for a tool. It does not have to be a full-time hire either: ten to twenty hours a month covers most of this, and the same question applies to a freelancer.

The rest of what a founder can check without reading code is here, and the order to automate the company in is here.