What a «Software Factory» Is — and Why a Company of Fifteen Should Not Buy One

«We are looking for a software factory.» I hear the phrase from Spanish and Latin-American buyers several times a year, and it always tells me two things before the conversation starts: they have bought outsourced development before, and it was bought by procurement. Because a factory is what you ask for when you think of software as units delivered against a specification, and that is a reasonable thing to think if the last vendor sold it to you that way.

I want to take the phrase seriously, because it has a real history and a real model behind it, and then explain why the model is the wrong shape for the company that most often asks me for one.

The phrase is fifty years old and was never about startups

«Software factory» is not a marketing coinage. It comes from the 1970s and 1980s, when large Japanese electronics firms — Hitachi, Toshiba, NEC, Fujitsu — organised software production on the model of their manufacturing plants: standardised processes, reusable components, measured productivity, thousands of engineers on long-lived systems. Michael Cusumano documented it in Japan's Software Factories (1991), and the idea travelled: to US defence contractors, to the CMM maturity models, and eventually to the outsourcing industry, where «factory» came to mean a large delivery organisation that turns specifications into code at a predictable cost per unit.

In Spain and Latin America the term stuck harder than anywhere else. Fábrica de software is what the big integrators call their offshore and nearshore delivery centres, and it is how corporates buy from them: a framework contract, a rate card by seniority, a change-request process, a service-level agreement on defects. The factory model optimises for predictability and volume across many projects, at the price of judgment on any one of them. That is not a flaw. It is what a bank with forty concurrent projects needs.

What the factory actually sells, and what it does not

Strip the branding and a software factory sells four things:

1. Capacity on demand — dozens to hundreds of engineers who can be assigned to your project and reassigned when it ends.
2. A repeatable process — requirements in, estimates out, delivery against a plan, defects tracked against an SLA.
3. Cost predictability — a rate card, often blended across seniorities, and a fixed price for well-specified work.
4. Organisational risk transfer — one contract, one account manager, one throat to choke.

What it does not sell, and cannot at that scale, is the thing a small company needs most: someone senior who decides what to build and takes responsibility for the decision being right. A factory executes a specification. When the specification is wrong — and at two to fifteen people the specification is always partly wrong, because the company is still discovering what it is — the factory's process delivers the wrong thing on time, then charges a change request to fix it. The blended rate card makes this worse: the engineer who could have told you the specification was wrong in week one is the senior one, and a blended rate is how you avoid paying for him.

Where the factory model is the right buy

I will give the model its due, because the strongest objection to this piece is «you sell squads, of course you dislike factories». Three cases where a factory is the right call:

• Volume with a stable specification. Migrating four hundred screens from one framework to another. Maintaining a regulated back-office system with a known change rate. Work where judgment has already been exercised and what remains is execution.
• Procurement-driven buying. A corporate whose purchasing rules require a framework supplier, an SLA and a blended rate cannot buy a five-person squad however good it is.
• Many small projects at once. A company running twenty concurrent internal tools benefits from one process across all of them more than from excellence on any one.

If you are one of those, buy the factory, and buy it from one of the large integrators who have run the model for decades. It is what they are for.

Why a company of fifteen gets a worse product from a factory than from five people

Now the company that actually asks me. Two to fifteen people, a founder or two, a product with early customers, an idea of the next version that is about sixty per cent right. Here is what the factory model does to that company, in the order it happens:

The specification phase takes six weeks and produces a document the founder signs without fully understanding, because the document is the factory's artefact, not theirs. The engineers assigned are the ones available, which at a blended rate means mostly mid-level, with a senior «architect» who appears in the steering meeting. The first release matches the document and misses the market, because the market moved during the six weeks and nobody on the delivery side was empowered to say so. The change requests begin. By month six the company has paid for two products and owns one, and it is the one from the document.

The alternative is not «hire in-house», which at fifteen people is slow and expensive. It is a small senior team — four or five people with a Tech Lead who owns the architecture — working inside the company's repository on a monthly retainer, with the founder in the standup and a demo every two weeks. That team costs more per hour than a blended factory rate and less per month than the factory, because it needs fewer hours to build the right thing. More importantly, it can tell you in week two that the specification is wrong, and it is paid to. That is the model I run, and I wrote the process down so it can be checked rather than believed.

How to tell which one you are being sold

Vendors in Spain now use «software factory», «squad», «dedicated team» and «partner» interchangeably, so the label tells you nothing. Four questions do:

1. «Who on your side can tell me my specification is wrong, and are they on the project every day?» A factory answers with a role in a steering committee. A squad answers with a name and a Slack handle.
2. «What is the seniority mix of the people actually assigned?» A blended rate hides it. Ask for the individuals and their track record on your kind of system.
3. «What happens when the scope changes in week three?» A change request with a price is the factory answer. A re-prioritised backlog at the next planning is the squad answer. Both are legitimate; only one fits a company still discovering its product.
4. «How does the engagement end?» Framework contracts have exit clauses measured in quarters. A retainer with 30-day notice ends when it stops being useful.

The short version

A software factory is a fifty-year-old manufacturing model for producing software at volume against a stable specification, and it works for the corporates it was designed for. A company of two to fifteen people does not have a stable specification; it has a hypothesis, and what it needs is a few senior people who can change the hypothesis while building it. That is a workshop, not a factory. Buy the one that fits the size of the bet you are making.

If you are trying to work out which one you need, we tell you in a 30-minute call — including when the answer is the factory.