How to Build Your Own Software Factory
-->
Navan
Something Funny
about/links
posts
3D designs
colophon
© 2019-2026. Navan Chauhan<br>RSS
Ai
How to Build Your Own Software Factory
6th May, 2026<br>18 min read
-->
How to Build Your Own Software Factory
The Dragon Scroll Is Blank
Brownfield Is Not the Problem
Don't Build a Worse Claude Code
What Are You Manufacturing?
Define the Seed
The No-Op Case Is Mandatory
Create the Task Packet
Validate Outside the Agent's Claims
The Output Is Not Code
A Reasonable Build Order
A Concrete Factory
Add Triggers Only After the Loop Works
Scale to Fleets
Build for Tomorrow's Models
Humans Move Upstream
The Failure Modes
The Question to Ask
In February, when we put out the StrongDM Software Factory work, I expected people to argue with it. I didn't expect the response to be as positive as it was, though I loved the discussion on HN. The funny part is that after all of that, we still get the same question: "How do I build my own software factory?"
That's not a bad question. I just think it's usually one question too early.
People hear "software factory" and picture a product. A thing you buy. A dashboard. A queue. A fleet of background agents. Jira tickets go in. Pull requests come out. Henry Ford, but with Claude Code instead of steel. Maybe there's a vendor page with three blue gradients and a tasteful diagram of boxes pointing at boxes. I get the instinct. I just don't think the useful thing is a single product-shaped object. There's no one-size-fits-all software factory. I don't think there should be one. Maybe I'll bite my tongue on that in a year — wouldn't be the first time reality deleted one of my confident sentences.
When you build an actual factory line, you don't just say "factory" and start manufacturing whatever object happens to be nearby. You retool the line. You build the molds. You decide what tolerances matter. You decide what gets inspected. You decide what gets rejected. You decide when the line stops. Same thing here.
A software factory isn't the agent. The agent is one machine on the line. The factory is the line. It's the work intake, the environment, the tools, the validation, the stopping rules, the evidence, the routing, the triggers, the retry logic, the escalation path, and the feedback loop. The factory is the system around the agent that lets you believe a terminal state without squinting at it for twenty minutes.
Sometimes that terminal state is a pull request. Sometimes it's a no-op. Sometimes it's "please ask a human because this ticket is fake." That distinction matters more than almost anything else.
The Dragon Scroll Is Blank
You are the software factory
If you've heard me describe this before, you've probably heard the Kung Fu Panda version. You are the software factory. Not because you personally should do all the work — that's the opposite of the point, and also a good way to become a haunted spreadsheet. You are the software factory because your current engineering process already contains the machinery. It's just mostly implicit.
You know when a ticket is bad. You know which logs matter. You know when a screenshot is suspicious. You know which test failure is real and which one is CI being CI. You know when the customer said "Slack" but meant "Slack Enterprise Grid with SCIM weirdness." You know which internal API lies on Tuesdays. You know what evidence would convince you.
The work is taking that judgment out of your head and making it executable. That's why this is hard. It's not just prompting. It's extracting taste, context, verification, risk tolerance, and operational scar tissue — then turning all of that into a system an agent can run through without you ferrying reality back and forth.
Brownfield Is Not the Problem
The first place my brain goes is brownfield. Not because it's clean. Because it's not. Brownfield is where this gets interesting.
Greenfield demos are easy. You ask the model to build a todo app. It builds a todo app. Everyone claps. Nobody has to care about the ancient auth middleware, the flaky integration test, the customer who depends on undocumented behavior, or the one migration that only runs correctly if the moon is in retrograde.
Brownfield has all the annoying stuff. That's also why brownfield has all the factory material. It has tickets. Logs. Runbooks. CI. Tests. Release rituals. Migration patterns. Known bad smells. Existing examples. Customer paths. Production incidents. The weird things senior engineers know but never wrote down because nobody wanted to spend a sprint making the codebase more legible. That's the stuff you turn into machinery.
A factory isn't "the agent can write code in an old repo." That's table stakes. The interesting version is: the agent can enter the same messy world a human enters, decide whether the task is real, make the smallest correct change, validate it against something outside its own claims, and hand back evidence a...