Why I open-sourced my software factory
You are not building a software factory. You are building the way your entire company works together.
I maintain OpenInspect, an open source software factory that enables teams from ten to five hundred engineers run on their own infrastructure. The question I get most often is why I open sourced it rather than selling it.
The short answer: The value is in the org process, not the infrastructure
What a Software Factory is
There are a lot of different definitions on what a software factory is, ranging from a pointing your local claude code at a linear issue to a fully-automated no-human interaction system. Either end of these are probably wrong, so i'll give my take:
A software factory is a system that takes a signal (issue, Slack message, alert, cron, user prompt) and converts it to an outcome: a PR, a fix, an answered question, using AI agents to drive the loop.
Organizations commonly use this to address bug fixes from Slack, feature creation from linear or JIRA, Code review, auto-healing CI, triaging on-call incidents, Q&A over a code base or documents, and general data questions.
Company agent infrastructure is probably a better name for this.
Selling it as a product is hard
Across software factories as a product, there are a common set of components being sold: control plane, sandboxes, harness, web UI, integration surfaces. These components are more/less commodity and all offer very similar functionality with most being sold $50-100/per seat/mo. Token usage is typically not included, or sold back to you at a premium on top of the underlying provider.
Selling this as a product is difficult.
You don't own the core drivers: sandboxes and the model inference and a large company has platform engineers who can easily replicate your offering at a fraction of the cost. The piece you could own, the control plane and harness, has been commodified and the points of interest: access control, environments, network policy, context and surfaces are hard to build a one-size fits all as every org's stance is different.
The common vendor answer to this is "forward deployed engineers", which is really just a consulting business with a fancier name.
The Org's Processes are the Value
The value of the software factory comes from building a system that fits and shapes how your company works.
Org level routing decisions
As less technical users are onboarded into the software factory, in most vendor products they are presented with the a large amount of options. Everything from agent personas, models, reasoning effort, number of sandbox CPUs. The results in everyone defaulting to Fable-tier models to answer basic Q&A questions as they aren't sure what the difference is between models, nor do they care.
What we want is a agent router that is abstracts over this.
For a vendor, this creates a very challenging problem in that they need to build a router that serves all of their customers, but the router itself is customized to the each company. You end up with a generic router that doesn't match your actual org chart and how the system needs to run.
Knowledge Distribution
Sharing context within the organization is a critical part of a company being successful with AI agents. This is commonly done through teammates creating skills, docs, and specialized tooling. In Uber's case, they have over 3,600 skills that execute over 30,000 times a day.
As usage grows within the system, it becomes a huge challenge for how skill discovery and skill approval works.
How to address these is very specific to each company depending on their org hierarchy. For it to be successful, it needs to be something that is actually matching how your company operates.
How You Improve
A system that doesn't learn is a system that continues to repeat the same mistakes.
Every session that runs provides us insight into the performance of the system and insight into the failures that are occurring across the organization.
In a provider owned system, It is often very challenging to access all of the session trajectories. As a result, there's limited ability to actually learn from prior sessions and learn from organization usage.
By directly owning the system, you have the ability to analyze all of your sessions and the failures that you do identify, you can fix them once across the entire system for everyone.
Cost Optimization
On a vendor-hosted factory, a common functionality is to expose an auto model selection. The challenge with a feature like this is that the approach for picking the best model for any given task heavily depends on the task itself.
The provider solution is going to be aggregated across all of the customers rather than tailored to your specific company's tasks. As a result, you end up with a suboptimal solution that is neither cost optimal nor performance optimal. The provider has no way of knowing what are the critical tasks within your system as that again is highly specific to your company.
Similarly, there is a bit of misaligned incentives, where the vendor's incentive to make money through the sale of tokens is against your interest to decrease the cost relative to performance.
ROI and Attribution of Token Spend
AI telemetry tells us which models our agents use and what they cost but not what we're paying them to actually solve.
As organizations cross what I call 'the token enlightenment', They shift away from tokenmaxxing and instead begin to focus on the actual ROI that the AI system is generating for them. The natural place to determine attribution as well as ROI is based on the session traces themselves.
In the best case scenario, you would be able to directly map your own ROI and attribution into the provider system. However, as Ramp outlined in their article about ROI and attribution, determining how you want to do attribution is an exercise within itself and is something that you and your team need to form a perspective on: everything from the task taxonomy to how you model cost centers.
So I gave it away
Having deployed software factories at companies everywhere from 10 engineers to 500 engineers, I saw a repeated trend where the system becomes critical infrastructure and as a result it's something that the company should directly own themselves.
Rather than try to productize this and put everyone in a closed system, I decided that the best path for the overall ecosystem was just to give it away.
This would allow teams to have a foundation to build upon and get themselves up to speed and be able to focus on the actual organization problems of the system rather than trying to work around vendors constraints.
Close
If you don't own the factory, you won't own the way your organization communicates together and operates going forward.
As part of my consulting, I help deploy software factories for teams and address a lot of the hard organizational problems mentioned above.
If any of this resonates with you, I would love to chat with you and your team. Reach out via DM or book time on my calendar