a guide for people with something to build
what is a
software factory?
A software factory is a repeatable system for turning requirements into working, tested software. It combines people, reusable components, tools and delivery practices. Some factories use AI agents; others rely on conventional development teams. The useful question is what the system can deliver reliably, and who takes responsibility for it.
Have a workflow to improve or a tool to build? Start with a free assessment, or check whether a build makes sense.
one term, several models
“Software factory” describes several related ideas. A company may mean an internal delivery capability, a platform that developers use, an AI-driven workflow, or a service you hire. Those are different buying decisions.
| Model | What it provides | What to establish |
|---|---|---|
| Internal software factory | A repeatable way for your own teams to build and release software. | Who owns the platform, delivery process and product decisions? |
| Developer platform | Shared tools, environments and delivery capabilities. | Does your team still need to design, build and operate the application? |
| AI software factory | Agents perform parts of implementation, testing or delivery. | Which decisions are automated, and what evidence is required before release? |
| Software factory as a service | A partner delivers software against an agreed scope. | What is included, what do you own, and who supports it afterwards? |
Software Facto uses the service meaning: bespoke software development, beginning with a free assessment and project-specific pricing. Scope, acceptance and responsibilities are agreed for each project.
Examples of the distinctions: the CNCF platform paper, StrongDM’s account of its AI factory, and Vercel’s AI software factory explainer.
how a software factory works
The “factory” idea is useful when it makes delivery repeatable without making every product identical. A sensible delivery loop connects the problem, implementation, evidence and operation. The sequence below is a buyer’s evaluation framework, not a universal industry standard.
- Define an outcome. Name the user, the job they need to finish and the constraints. “Reduce duplicate order entry” is more useful than “build an AI dashboard”.
- Agree the acceptance examples. Describe a normal case, a difficult case and a failure case. Decide what evidence will count as working software.
- Build a small complete slice. Connect enough of the real workflow to test the important assumptions. Reuse components where they fit; document what is specific to the project.
- Verify the result. Check behaviour, permissions, integrations and recovery. A successful demonstration is one piece of evidence; it does not establish every operational requirement.
- Release and operate. Establish ownership, access, hosting costs, monitoring, rollback and support. Decide how later changes will be assessed.
Automation can help at each stage. It does not resolve an unclear business requirement or decide, by itself, what level of risk is acceptable. Ask for a visible acceptance record connecting a requirement to a result and its reviewer.
what AI changes
AI agents can take a larger role in turning a task into a code change. The surrounding system still matters: context, tools, isolated environments, tests, review and release controls.
In February 2026, StrongDM described a factory driven by specifications and scenarios, with no human code review. Stripe’s account of its Minions described unattended coding agents whose pull requests still received human review. The companies’ accounts illustrate different choices about supervision and acceptance.
For a buyer, an “AI software factory” label should lead to more specific questions: what can the agent change, which checks can it not bypass, and who accepts the result? Our comparison of current AI factory approaches examines these boundaries.
when does a bespoke build make sense?
Start with the work you need to improve. A bespoke tool is worth investigating when an important workflow cannot be served adequately by existing products, or when several systems need to work together in a way that standard integrations do not support.
- Internal tools: a focused interface for a task that currently depends on repeated handovers, spreadsheets or copied data.
- Workflow automation: a repeatable process across systems, with explicit rules, exceptions and a person responsible when something fails.
- A new product: a small version that lets intended users test the core workflow before a larger investment.
A bespoke build may be the wrong choice if a standard product covers the essentials, the process is still changing, or nobody can own the result. Buying a tool, configuring what you already use, or changing the process may be enough.
Use the build, buy or automate decision tool to identify the next question to resolve. It explains its rules and gives you a short brief without collecting your answers.
factory, agency, platform or team?
A software agency and a software factory service can offer overlapping work. An agency describes a business relationship; “factory” usually emphasises a repeatable delivery process. Neither label proves quality or determines what is in the contract.
A development platform gives a team capabilities to use. A delivery service takes on an agreed piece of work. An in-house team may offer more continuity and accumulated product knowledge, while a project-based partner may suit a bounded need. The appropriate choice depends on recurring work, available expertise and how much ongoing ownership you need.
Compare the actual proposal: outcome, scope, dependencies, acceptance, access, cost and support. If those differ, the labels are hiding different offers. The software factory buyer checklist turns this into specific questions.
what does a software factory cost?
There is no single useful price for an unspecified software project. The number of workflows, integrations, data migration needs, permissions, reliability requirements and support responsibilities all affect the work. AI use alone does not determine the final cost.
At Software Facto, the initial assessment is free. Development is quoted separately after a scope is understood. There is no published flat subscription price or guaranteed delivery time.
Ask a provider to distinguish the build price from hosting, third-party services, model usage where relevant, maintenance and later changes. Agree who pays for each item and what happens when usage or scope changes. A comparison that omits operating costs is incomplete.
what happens in a free assessment?
Start by describing the problem or idea, who it is for and the outcome you want. Include the systems involved, a deadline or budget if you have one, and the main uncertainty. You do not need a finished technical specification.
The assessment is a chance to explore whether a bespoke build is sensible and what a useful first scope might be. If there is a fit, development follows a separate proposal and price.
A useful first message
“Our operations team copies approved requests from one system into another. We want to remove that duplicate step while keeping someone in control of exceptions. We use [systems], and we need to understand what is feasible.”
This is an illustrative brief. Do not send passwords, private customer records or production credentials.
a few useful answers
does a software factory have to use AI?
No. The term predates modern coding agents. Reuse, standardised practices and repeatable delivery have a longer history. AI changes which parts of the work can be automated; it is not a prerequisite for using the term. See our sourced history of the software factory.
can it work with an existing system?
That depends on the system’s interfaces, access permissions, data quality and the changes required. An assessment should establish those constraints before promising an integration.
who owns the software?
Establish source access, intellectual property rights, third-party licences, hosting accounts and handover in the project agreement. The words “bespoke” or “factory” do not settle those questions.
how do you know it works?
Agree observable acceptance examples before implementation, then test them against the delivered system. Include failure and recovery cases where they matter. Ask to see evidence and unresolved limitations, alongside the demonstration.