Local-First Conf 2026 sold out. Three hundred and fifty people packed into Festsaal Kreuzberg in Berlin this past weekend, July 12 through 14, to talk about data ownership, offline-capable apps, and sync engines. Adam Wiggins, who co-founded Ink & Switch and has been making the case for local-first architecture since 2019, ran the closing lab day. This year’s theme made that explicit: “user empowerment in an age of fluid software,” not just local-first as a technical pattern.
That phrase is the interesting part. Fluid software is the idea that AI coding tools have made building an app cheap enough that apps stop being durable products and start being disposable, one-off tools you generate for a single task and discard. Ask an agent to build you an expense splitter for a trip, use it for a week, throw it away. Multiply that by every small, specific need a person or a business has, and you get a world where most software has the lifespan of a browser tab.
We think that idea is half right, and the half that’s right has a consequence most people building this way haven’t thought through.
The part that’s true
AI-assisted coding really has changed the cost of building something narrow and specific. We use these tools ourselves, and our ai-assisted engineering work is built around that shift. A tool that used to take a two-week sprint can now take an afternoon of an engineer directing an agent, reviewing the output, and fixing what it got wrong. For a genuinely single-use script, that’s a real win. Nobody needs a maintained product to convert a CSV once.
Where we push back is the leap from “building software is cheap now” to “software itself should be treated as disposable.” Most of what businesses actually need isn’t a one-off script. It’s something that runs for years, gets used by people who depend on it working the same way tomorrow as it did today, and accumulates data that matters. A field service app a technician uses every day. A patient intake tool a clinic runs for a decade. An inventory system a warehouse can’t afford to have vanish. None of that is fluid, and treating it as if it were is how you end up with a pile of AI-generated tools nobody can safely retire because nobody knows what depends on them.
The data doesn’t get to be disposable
Here’s the consequence people skip past. Even if the app is disposable, the data it touches usually isn’t. If you generate a tool that tracks customer orders, logs sensor readings, or stores anything a person or a business needs next month, you’ve created a dependency that outlives the tool’s expected lifespan whether you planned for that or not. Throw away the app and you’ve either thrown away the data with it, or you’ve quietly built a migration problem you’ll deal with later, under worse conditions.
This is exactly the argument local-first architecture has been making for years, and it’s why the framing at this year’s conference landed the way it did. If software is going to get cheaper and more disposable to build, the thing that has to be stable is the data layer underneath it. Data that lives on the user’s device, in a format the user (or the business) controls, synced through a protocol that doesn’t assume any particular app is the permanent owner of it. CRDTs, which came up constantly in Berlin and got their own devroom at FOSDEM earlier this year, exist specifically to let multiple replicas of that data merge without a central server arbitrating every write. That’s not an academic curiosity. It’s the mechanism that lets you swap out the app on top without losing or corrupting what’s underneath.
We build this pattern into our local-first software work for exactly this reason: the app is going to change, get rebuilt, get replaced by something better in three years. The data shouldn’t have to.
What this means if you’re planning a build
If you’re a founder or technical lead using AI tools to move faster on a real product, and you should be, separate two decisions that are easy to conflate. One is how fast you build and iterate on the interface and the logic layer. That can and should move quickly, and AI-assisted development is legitimately good at that. The other is where the data lives and who controls its format, and that decision needs to be made deliberately, not as a side effect of whichever framework the agent defaulted to.
Concretely: don’t let your data model live entirely inside a vendor’s proprietary sync service if you expect to still be running this product in five years. Don’t let “we’ll figure out data ownership later” be the plan, because later is after you have real customers depending on the current format. And don’t assume that because the app was cheap to build, the data it holds is similarly low-stakes. Cheap software plus expensive data is a bad combination, and it’s becoming a more common one.
The honest tradeoff
Local-first isn’t free. Sync logic is genuinely harder to get right than “write to a database and call it done,” and for some products, a plain server-backed architecture is the correct, boring choice, especially if the data is inherently centralized (billing, multi-tenant reporting, anything that needs a single source of truth by nature). We’d tell you that directly if you asked us to build it. But for products where the user’s data belongs to the user, where offline use matters, or where you want the app layer to be replaceable without a painful migration, the case got stronger this year, not weaker, precisely because the software wrapped around that data is getting easier to throw away.
If you’re weighing this for a product, get in touch.