A local software factory is a system that keeps product, code and evidence connected on the machine in front of you. Not a chat window. Not a folder of Markdown. Not a tab in someone else’s cloud. A place where an idea becomes a decision, a decision becomes a specification, a specification becomes work an agent can execute, and the result comes back with proof attached — all in one connected system, all local.
That is a category claim, so I will defend it instead of asserting it.
Code generation is basically solved. Claude Code, Codex and the rest write code well enough that “can the model write this function” is no longer the interesting question. The work did not disappear. It moved. Now the job is keeping the product contract alive while many agents write, fail, recover, integrate and produce evidence. Today one person does that by hand, without a name for it. You are the scheduler. You are the memory between sessions. You are the recovery loop when a run dies. You are the quality gate that decides what “done” means. You are the runtime.
A factory is what you build when you get tired of being the runtime by hand.
The disconnection tax
Watch how a change actually moves through a modern AI-assisted workflow.
The idea starts in a chat. The decision to build it lives in your head, maybe in a Slack thread. The requirements end up in a Notion page or a Linear ticket. The agent gets a prompt that paraphrases some of that. The code lands in a repository. The tests, if they ran, printed output that scrolled off the terminal an hour ago. The reason you rejected the other approach is gone. Three weeks later, a second agent — or you, having forgotten — opens the file and sees a diff with no memory around it.
Every one of those handoffs loses something. That loss is a tax, and it compounds. The faster the agents write, the more of it you pay, because the volume of changes grows while the connective tissue does not. A green build tells you the code compiled. It does not tell you the behavior you promised got installed, or that the constraint you cared about still holds.
This is the real problem with AI-generated code, and it is not that the code is bad. Each piece is usually locally correct. The system drifts toward globally incoherent because nothing holds the whole together. The tools each own one slice — the editor owns the diff, the tracker owns the ticket, the chat owns the conversation — and no tool owns the through-line from intent to proof.
A factory is the answer to that specific failure: put the slices in one system so the through-line survives.
What connects inside the factory
I use the word factory deliberately, and also carefully. Not a feature factory — the machine that measures itself by output shipped and calls that product. The opposite. A factory here is a place with stations, where material enters, gets worked in a defined order, and leaves as something proven. Six stations, one loop.
Discover. Turn an uncertainty into a hypothesis, evidence, a small experiment and a decision. The output is a decision, recorded, not a vibe you’ll misremember.
Define. Keep the product contract — the PRD, the epics, the stories, the acceptance criteria — as something traceable, not a document nobody reads. The output is a contract an agent can be held to.
Plan. Refine scope, size the work, manage dependencies, make the sprint visible. The output is bounded work.
Build. Hand the engine a prepared contract, isolated context and an executable definition of done. The output is a change, not a hope.
Verify. Gates, tests, screenshots, traces. No evidence, no green light. The output is proof, not a self-report.
Learn. Feed the outcome, the code history and the decisions back into memory so the next loop starts smarter. The output is memory.
Each station produces context for the next. Nothing important is trapped in a prompt or abandoned in a planning doc. That is the whole trick, and it is unglamorous: the value is not in any one station, it is in the fact that they are connected and the connection is durable.
A product graph over a code graph
The connective tissue has a shape. Underneath, there is a code graph — the functions, files, services and their relationships, the thing a coding agent actually needs instead of a bigger prompt. Above it sits a product graph: discovery evidence linked to decisions, decisions to specifications, specifications to stories and criteria, criteria to the code that implements them, and code back to the evidence that validates it.
Most tools flatten your product into a list of tickets and lose the links. The point of the graph is that the links are first-class. You can open any capability months later and recover four things at once: what it does, why it exists, where it lives, and what proves it works. That is the difference between a system that remembers and a pile of artifacts that happen to share a folder.
When an engine can route work across different models without vendor lock-in, the graph is what survives the switch. The model is interchangeable. The memory is not, and the memory is what you actually own.
Why local is architecture, not nostalgia
Here is where the category earns its name. “Local” is not a preference for the old days. It is the only substrate on which all of this stays connected without asking you to trust a chain of third parties with the entire shape of your product.
Think about what the factory holds: your discovery notes, your rejected options, your unshipped bets, your acceptance criteria, your code, your test evidence. That is not a repository. That is the strategy behind the repository. The question of where that lives is an architecture decision, and it deserves the same seriousness you would give to choosing a database.
Put it on your machine and three things become true by construction, not by policy. The state is next to the work, so the latency between “I decided this” and “the agent sees it” is a disk read, not a network round-trip and someone else’s rate limit. The data is yours, in inspectable storage you can open, so privacy is a property of the architecture rather than a promise in a settings page. And nothing about the system depends on a vendor staying in business, keeping their pricing, or not changing their terms.
Local does not mean closed, and that distinction matters. The factory runs on your computer, but it calls the AI providers you choose, works in ordinary git repositories, and stays open at the boundaries where portability matters. The models are remote — that is the plain truth, and the cloud genuinely does inference better than your laptop will. What stays local is everything that defines your product: the contract, the graph, the decisions and the proof. You send tokens out when you choose to. You do not hand over the factory.
What the cloud does better, and what that costs
I am not going to pretend the trade is one-sided. Cloud tools are excellent at some things a local factory is not. Shared state across a team, with no setup, works the moment someone opens a browser. Heavy compute is somebody else’s problem. The software updates itself. For a large team that lives in one shared workspace, those are real advantages and I would not wave them away.
The cost of that convenience is exactly the thing this category is about. When the state lives in someone else’s cloud, your product’s memory is a tenant, not an owner. The connection between intent and proof exists at their discretion, in their format, exportable on their terms. You are renting the through-line. For a solo founder or a small team building something they intend to still understand in a year, owning that through-line is worth more than the setup it saves.
That is the real version of the choice, and it is a choice, not a verdict.
The factory of one
The reason this matters now, and not five years ago, is that agents changed the unit economics of building. A single person with a working factory can hold more moving software in their head than a small team could before, because the system is holding the parts the person used to hold by hand. The scheduler, the memory, the recovery loop, the gate — those were the ceiling on how much one person could run. Move them into a system and the ceiling rises.
That is the promise, and I want to be exact about it: not that you’ll ship 40% faster, not any number I would have to invent. The claim is structural. When product, code and evidence stay connected on your machine, you spend less of your day being the connective tissue and more of it deciding what should exist. Building got cheap. Deciding got expensive. A factory is where you put the cheap part so you can afford to do the expensive part well.
Stop being the runtime by hand
Here is the test of whether any of this landed. Think about your last hard week of shipping with agents. Count the hours you spent not building, not deciding, but holding things together: re-explaining context a session lost, hunting for why a decision was made, re-running work because you could not trust a “done”, carrying the plan between tools in your own head. That was you being the runtime. It does not show up in any changelog, and it is most of the job now.
A factory does not make that work disappear by magic. It makes it the system’s job instead of yours. The scheduling, the memory, the recovery, the gate — the parts you were doing by hand — move into something that holds them durably, connected, on your machine. What is left for you is the part that was always yours to do: deciding what should exist and judging whether it did. That is the trade the category is built to make.
Where to go deeper
The factory is easier to grasp one station at a time. The case for keeping the whole system on your machine is the local-first argument for AI development, and the sharpest version of it is why your code should stay on your machine even when the models are not. That stance has a native home in the macOS-native tools it runs on, and it comes with smaller freedoms too, like tools that need no account.
On the model side, a factory routes work to whatever model you bring and gives you a place to keep AI costs under control instead of watching them float. The real comparison with the alternative is laid out in cloud versus local AI tools. And the reason all of this matters now is economic: it is what makes a factory of one possible. For the operating picture the whole factory sits inside, start with building software with AI agents.
Where PaellaDoc fits
PaellaDoc is the local software factory I am building because this problem is mine before it is anyone else’s. It runs on macOS, local-first, free for up to three projects, no account required. It connects discovery, decisions, specifications, agents, the code graph and the evidence into one system on your machine, and calls whatever models you point it at. Product data, repositories and proof stay local; the manifesto is the longer version of why.
I did not invent the local software factory as a marketing frame and then look for a product to fit it. I built the product because being the runtime by hand stopped scaling, and then I noticed the shape of what I had built was a category. This piece is me naming it plainly. The agents will keep getting better at writing code. The scarce thing — a place where your product, your code and your proof stay connected, and that place is yours — is the thing worth building.
Frequently asked questions
What is a local software factory?
A local software factory is a system that keeps product, code and evidence connected on your own machine. An idea becomes a decision, the decision a specification, the specification work an agent can execute, and the result returns with proof attached — all in one connected system instead of scattered across a chat, a tracker and a repository. Local means the through-line from intent to proof is yours to own, not rented.
Is a local software factory the same as a feature factory?
No, it is the opposite. A feature factory measures itself by output shipped and calls that product. A software factory is a place with stations — discover, define, plan, build, verify, learn — where material enters, gets worked in order, and leaves proven. The point is not the volume of features. It is that intent, code and evidence stay connected so the system stays coherent while agents write.
Do I need to run the AI models locally?
No. Local refers to where your product’s state lives, not where inference runs. The factory sits on your machine but calls whatever AI providers you choose, and the cloud does inference better than a laptop will. What stays local is everything that defines the product: the contract, the graph, the decisions and the proof. You send tokens out when you decide to, without handing over the factory.
Is a local software factory only useful for solo developers?
It matters most for a solo founder or small team building something they intend to still understand in a year, because owning the through-line beats the setup a shared cloud saves. Large teams gain real things from cloud tools: shared state with no setup, heavy compute as someone else’s problem, self-updating software. The choice turns on whether owning your product’s memory outweighs that convenience.