In local-first AI development, the models can live in the cloud, but the system around them lives on your machine. The orchestration, the state, the memory between sessions, the verification, the recovery loop — those run on your Mac. The inference is a call you make out and a result you bring back.
That split is not a compromise. It is the design. And it took me a while to see why it is the right one, because the loudest version of “AI development” today assumes the opposite: that everything, including the system that coordinates the work, belongs in someone’s browser tab.
Let me argue the split the way it actually bites, from the pain you feel every day to the pain you feel once a quarter.
Latency: the tax you pay every single loop
The agentic loop is tight. Read state, decide, act, check, update state, repeat. You run that loop hundreds of times a day, and every time the state has to travel to a server and back, you pay for the round-trip.
It is not the raw milliseconds that hurt. It is what they do to your attention. A local read is under the threshold where your mind wanders. A network round-trip through someone else’s queue, subject to their rate limits on a busy afternoon, is often over it. Cross that threshold enough times and you stop being in flow and start being a person waiting for tabs.
When the factory state is a SQLite file on your disk, the latency between “I decided this” and “the agent can see it” is a disk read. The only thing you wait on is the model, which you were always going to wait on. Everything else is instant because everything else is local. That is the difference you feel first, and it is the one that decides whether the tool disappears into the work or sits between you and it.
Cost: metered where it should be, free where it shouldn’t
Here is a distinction the cloud pricing model quietly erases. Some of what you do is expensive to run — model inference, genuinely. Most of what you do is cheap: reading your own decisions, browsing your own graph, checking what an agent did, re-running a gate. In a fully cloud tool, all of it sits behind the same meter, because storage, compute and coordination are all the vendor’s to bill.
Local-first puts the meter only where the real cost is. Inference costs what the provider charges, and you pay it directly, on your own API key, with no platform margin stacked on top. Everything else — the reads, the coordination, the state — costs nothing per operation because it happens on hardware you already own. You can browse your product graph a thousand times and it is free. You route the expensive work to the right model without vendor lock-in, and you keep the cheap work off any meter at all.
This also changes what you are willing to do. When coordination is free, you coordinate more carefully. When every read is metered, you read less, and you make worse decisions with less context because context has a price. Free local operations are not a rounding error. They change your behavior toward the system.
Privacy: a property, not a promise
Your code is the least of it. The factory holds the parts you would never paste into a public channel: the strategy, the rejected bets, the security-sensitive constraints, the acceptance criteria that describe exactly how the sensitive thing is supposed to work.
When that lives on your disk, privacy is a property of the architecture. Nobody has to promise not to look, because there is nothing to look at on their side. You decide, per call, which snippet of context goes to which provider. The default is that the shape of your product stays home.
Let me draw the boundary precisely, because the precise version is more useful than the marketing one. When you call a remote model, the tokens you send go to that provider, under their terms. Local-first does not make that disappear. What it does is make it a decision you take on purpose, one call at a time, instead of a default where your entire workspace is continuously synced to a server as the price of using the tool. That is the whole point of treating privacy as an architecture decision rather than a checkbox: the question stops being “do I trust their policy” and becomes “what am I choosing to send”.
Control: the one that bites once a quarter but bites hard
Latency annoys you daily. Cost nags monthly. Control is the one you forget about until the day it matters, and then it matters completely.
A vendor changes their pricing. Deprecates the feature your workflow depended on. Gets acquired and sunset. Changes their terms in a way you would not have agreed to if asked. Goes down on the afternoon you shipped. When your factory lives in their cloud, each of those is your problem, and you have no move except to accept it or migrate under duress.
When the factory is local and open at its boundaries — ordinary git repositories, inspectable storage, models you can swap — none of those events can take your system from you. The provider going away costs you that provider, not your product’s memory. This is the least glamorous of the four reasons and the one I would refuse to give up. Owning the thing you are building on is not a nostalgia; it is the difference between a tool and a dependency you cannot see the bottom of.
What local-first is not
It is not offline maximalism, and it is not a claim that your laptop should do the inference. Frontier models run in datacenters for good reasons, and pretending a 16-inch MacBook competes with that would be a lie. Local-first is not anti-cloud. It is specific about which parts belong where.
The rule is simple. The thing that is genuinely expensive and genuinely improved by scale — inference — can be remote. The thing that defines your product and that you should own — the contract, the graph, the decisions, the proof — stays local. You are not rejecting the cloud. You are refusing to rent the parts you should own.
And notice that the four reasons stack rather than compete. The same design choice that gives you disk-speed latency is the one that keeps the coordination off a meter, keeps the shape of your product off a server, and keeps a vendor’s bad day from becoming yours. You do not trade one against another. Putting the system on your machine buys all four at once, which is why local-first is a single decision and not four separate features you have to assemble.
Where PaellaDoc fits
PaellaDoc is the local software factory built local-first for exactly these four reasons. It runs on native macOS tools, keeps your product graph, repositories and evidence in local storage on your machine, and calls whatever models you choose — cloud providers on your own keys, or local engines — without routing your workspace through anyone’s server. Free for up to three projects, no account required.
The models will keep getting better, and they will keep living in datacenters. That is fine. The system that turns a model into a factory — the part that schedules, remembers, verifies and recovers — is the part that should live where you can see it, on the machine in front of you.
Frequently asked questions
What does local-first AI development mean?
Local-first AI development keeps the system around the models on your machine while the models stay remote. The orchestration, state, memory between sessions, verification and recovery run on your Mac; inference is a call you make out and a result you bring back. The split is deliberate. The expensive part that scale improves can be remote, while the parts that define your product stay local.
Is local AI development private?
Privacy becomes a property of the architecture rather than a promise. Your strategy, rejected bets and acceptance criteria live on your disk, so there is nothing on a vendor’s side to look at. The precise boundary: when you call a remote model, the tokens you send go to that provider under their terms. Local-first makes that a per-call decision you take on purpose, not a default where your whole workspace syncs to a server.
Do I need to run AI models on my own computer to be local-first?
No. Local-first is not offline maximalism and does not claim your laptop should do inference. Frontier models run in datacenters for good reasons. What stays local is the contract, the graph, the decisions and the proof — the parts that define your product and that you should own. The models remain remote, called on your own keys. You refuse to rent the parts you should own, not the cloud itself.
Is local-first development slower than cloud tools?
It is usually faster where speed matters. The agentic loop reads state, decides, acts and updates hundreds of times a day. When state is a SQLite file on your disk, each read is disk-speed instead of a network round-trip through someone’s rate limits. The only thing you wait on is the model, which you were always going to wait on. Everything else is instant because everything else is local.