The Quiet Tech Shift: How “Local-First” Tools Are Replacing the Cloud for Everyday Work
Cloud outages made a hidden dependency obvious: everyday work now lives on servers you don’t control. Local-first tools flip the model—store locally, sync when possible, keep collaboration without fragility.
By TheMurrow Editorial
January 10, 2026
Key Points
- 1Recognize cloud fragility: major 2025 Microsoft 365 and Azure outages show everyday work can collapse when distant servers fail.
- 2Adopt local-first thinking: keep a complete on-device copy, work offline, and let sync accelerate collaboration instead of gating it.
- 3Weigh new tradeoffs: CRDT-based merging enables resilience, but endpoint data, backups, recovery, and key custody become first-class responsibilities.
The most unnerving part of a cloud outage is how ordinary it feels while it’s happening. A document refuses to open. A calendar won’t load. A team chat goes silent. Nothing is “broken” on your laptop—yet your workday collapses anyway, because the server you don’t control has become the single point of truth.
That fragility is no longer a niche concern limited to IT departments. Reuters reported that a Microsoft 365 outage on October 9, 2025—caused by a misconfigured portion of network infrastructure in North America—triggered a Downdetector peak of roughly 17,000 user reports. Later that month, Reuters reported a global Azure outage on October 29, 2025 that lasted more than eight hours, with complaints peaking at over 18,000.
After enough days like that, a simple question stops sounding ideological and starts sounding practical: why does a note, a draft, or a project plan need a constant network connection to be usable?
A growing movement in software offers a different answer. It’s called local-first—and it’s less about rejecting the cloud than dethroning it.
“Local-first isn’t nostalgia for the desktop era. It’s a demand that your work remain yours—even when the network doesn’t cooperate.”
— — TheMurrow Editorial
Local-first software, explained without the mythology
Local-first software has a precise, almost modest goal: put a complete, usable copy of your data on your device first, then sync with other devices and collaborators when possible. The app should remain fast and functional on a plane, in a basement, or during a provider incident. The server is still useful—often essential—for sharing and collaboration, but it stops being the only place your work “exists.”
Local-first is not “local-only”
Proponents often stress the distinction: local-first, not local-only. WIRED captured the spirit of the idea by describing software that de-emphasizes the server as the “single point of truth and failure,” while still supporting modern features such as collaboration and multi-device access. The cloud remains part of the picture, but no longer holds your work hostage to connectivity.
What changes for the user
Local-first design tends to show up as a set of user-facing promises:
- Offline-first functionality: you can create, edit, and search when disconnected.
- Responsive performance: work happens locally, not as a round trip to a data center.
- Meaningful control over data: often including user-held encryption keys, depending on the tool’s security model.
- Sync as a background service: the network becomes an accelerator, not a gatekeeper.
Local-first also clarifies a messy reality: “cloud” doesn’t mean “reliable,” and “offline” doesn’t mean “antisocial.” The movement is trying to keep collaboration while removing dependence.
- Offline-first functionality: you can create, edit, and search when disconnected.
- Responsive performance: work happens locally, not as a round trip to a data center.
- Meaningful control over data: often including user-held encryption keys, depending on the tool’s security model.
- Sync as a background service: the network becomes an accelerator, not a gatekeeper.
Local-first also clarifies a messy reality: “cloud” doesn’t mean “reliable,” and “offline” doesn’t mean “antisocial.” The movement is trying to keep collaboration while removing dependence.
Local-first promises users can actually feel
- ✓Work offline: create, edit, and search without a connection
- ✓Stay fast: avoid round trips to a data center for everyday actions
- ✓Hold real control: often including user-held encryption keys, depending on the model
- ✓Sync quietly: treat the network as a background accelerator, not a gatekeeper
Why the cloud suddenly feels fragile to everyday workers
The cloud has always failed sometimes. What’s new is how directly those failures are felt by people who don’t think of themselves as “technical,” and how large the blast radius has become when a few systems sit underneath everyone’s tools.
Reuters’ reporting on 2025 outages helped quantify the experience. On October 9, 2025, the Microsoft 365 disruption was tied to a network misconfiguration in North America and generated roughly 17,000 Downdetector user reports at peak. On October 29, 2025, Azure suffered an outage lasting over eight hours, with user complaints peaking at more than 18,000.
Those numbers matter because they represent a wider shift: centralized SaaS platforms increasingly function like utilities. When they stumble, the failure isn’t limited to one company’s website; it ripples across documents, identity systems, collaboration platforms, and workflows.
Reuters’ reporting on 2025 outages helped quantify the experience. On October 9, 2025, the Microsoft 365 disruption was tied to a network misconfiguration in North America and generated roughly 17,000 Downdetector user reports at peak. On October 29, 2025, Azure suffered an outage lasting over eight hours, with user complaints peaking at more than 18,000.
Those numbers matter because they represent a wider shift: centralized SaaS platforms increasingly function like utilities. When they stumble, the failure isn’t limited to one company’s website; it ripples across documents, identity systems, collaboration platforms, and workflows.
17,000
Approximate peak Downdetector user reports during the Reuters-reported Microsoft 365 outage on Oct. 9, 2025.
8+ hours
Length of the Reuters-reported global Azure outage on Oct. 29, 2025—long enough to turn dependency into a lost workday.
18,000+
Peak user complaints during the Reuters-reported Azure disruption on Oct. 29, 2025.
Risk data points to a trend, even if it’s imperfect
A commercial report can’t settle the question alone, but it can reinforce what users already feel. Parametrix’s Cloud Outage Risk Report 2024—as summarized on its own site—claims “critical” interruption events among AWS, Azure, and Google Cloud increased 18.0% in 2024 vs. 2023 and lasted 18.7% longer. It also recorded six events lasting more than 10 hours, totaling nearly 100 hours.
That’s not definitive proof of a deteriorating cloud. It is a reminder that when work is centralized, duration matters as much as frequency. A short incident is an annoyance; an eight-hour outage is a lost day.
That’s not definitive proof of a deteriorating cloud. It is a reminder that when work is centralized, duration matters as much as frequency. A short incident is an annoyance; an eight-hour outage is a lost day.
18.0%
Parametrix summary claim: increase in “critical” interruption events across AWS, Azure, and Google Cloud in 2024 vs. 2023.
“Centralization buys convenience—until it concentrates failure into a single, ordinary-looking error.”
— — TheMurrow Editorial
The technical ingredient that made local-first plausible: CRDTs
Local-first isn’t just a product philosophy; it’s also a technical wager. The wager is that many kinds of collaborative work can be modeled so that multiple devices can edit independently—and later reconcile—without corrupting the result.
The mechanism most often cited is the CRDT: Conflict-Free Replicated Data Type. WIRED described CRDTs as a major tool for conflict-tolerant collaboration, with a “Git-like” intuition: changes can be merged deterministically even when edits happen in different places at different times. Academic work “fleshed out” CRDTs around 2011, and their practical impact has grown steadily as collaboration and offline use became baseline expectations.
The mechanism most often cited is the CRDT: Conflict-Free Replicated Data Type. WIRED described CRDTs as a major tool for conflict-tolerant collaboration, with a “Git-like” intuition: changes can be merged deterministically even when edits happen in different places at different times. Academic work “fleshed out” CRDTs around 2011, and their practical impact has grown steadily as collaboration and offline use became baseline expectations.
What CRDTs solve—and what they don’t
CRDTs are designed for a hard problem: two people edit the same data while disconnected. The system later syncs and still arrives at a consistent result across devices without requiring a single “master” server to arbitrate every keystroke.
Local-first advocates lean on CRDTs because they enable:
- Offline edits with later reconciliation
- Real-time collaboration without a central authority for every operation
- Resilience against intermittent connectivity
CRDTs don’t magically eliminate complexity. They shift it. Developers still have to decide what “merge” should mean for a given product, and users may still encounter odd edge cases. But CRDTs demonstrate that “the server must be the truth” was always a design choice, not a law of physics.
Local-first advocates lean on CRDTs because they enable:
- Offline edits with later reconciliation
- Real-time collaboration without a central authority for every operation
- Resilience against intermittent connectivity
CRDTs don’t magically eliminate complexity. They shift it. Developers still have to decide what “merge” should mean for a given product, and users may still encounter odd edge cases. But CRDTs demonstrate that “the server must be the truth” was always a design choice, not a law of physics.
What CRDTs enable for local-first apps
- ✓Edit offline and reconcile later
- ✓Collaborate in real time without a central authority for every operation
- ✓Stay resilient through intermittent connectivity
- ✓Accept tradeoffs: merge semantics still require design choices and can create edge cases
The intellectual roots: Ink & Switch and the manifesto moment
The “local-first software” framing is widely associated with researchers and collaborators around Ink & Switch, including Peter van Hardenberg and Martin Kleppmann. Mainstream coverage, including WIRED, points to a 2019 white paper/manifesto and the momentum it sparked in developer communities.
That origin story matters because local-first isn’t only a reaction to outages. It’s also a coherent critique of how software quietly rearranged user agency over the last decade.
That origin story matters because local-first isn’t only a reaction to outages. It’s also a coherent critique of how software quietly rearranged user agency over the last decade.
Control, privacy, and the quiet question of who holds the keys
Local-first resonates because it reframes “data ownership” in a way that feels concrete. If your device holds a full working copy of your notes, drafts, or project history, the default power relationship changes. You can keep working without permission from a service. You can choose when to sync. In some designs, you can even hold the encryption keys that make the data readable.
That doesn’t automatically make local-first tools private or secure—but it makes certain forms of control technically possible.
That doesn’t automatically make local-first tools private or secure—but it makes certain forms of control technically possible.
A more realistic promise than “delete your account”
Traditional SaaS products often offer exports, backups, and account deletion. In practice, users still experience dependency: the tool is the workflow; the workflow is the archive. Local-first changes the center of gravity. Your “primary” copy exists where you are, and the cloud becomes a synchronization layer rather than the vault.
That’s why local-first feels aligned with ordinary user instincts: keep a copy of what you make.
That’s why local-first feels aligned with ordinary user instincts: keep a copy of what you make.
The tradeoff: responsibility returns to the user
A full local copy introduces a different risk: devices get lost, stolen, or corrupted. Local-first does not remove the need for backups; it increases the need for them. The mature version of this movement won’t pretend otherwise. It will treat backup, recovery, and key management as first-class product features—rather than as a support article you find after disaster strikes.
“Local-first restores autonomy, but it also restores responsibility—especially for backups and recovery.”
— — TheMurrow Editorial
Key Insight
Local-first shifts power by default: your device holds the primary, usable copy of your work, and syncing becomes optional rather than required.
Policy pressure is making “switching” a serious requirement
Local-first is rising amid a broader backlash against lock-in. Some of that is cultural: people are tired of being trapped in subscriptions and proprietary formats. Some of it is regulatory, especially in Europe, where portability has become a policy priority.
The EU Data Act is one example of that direction. The European Commission’s explainer emphasizes reducing barriers to switching between cloud and data processing services. The law targets portability and open interfaces, and it moves toward eliminating switching charges.
A headline detail deserves attention: the Commission’s explainer says the Data Act will entirely remove switching charges (including data egress fees) from 12 January 2027. That date signals more than consumer friendliness. It indicates a future where businesses—and eventually individuals—can treat cloud providers less like landlords and more like vendors.
The EU Data Act is one example of that direction. The European Commission’s explainer emphasizes reducing barriers to switching between cloud and data processing services. The law targets portability and open interfaces, and it moves toward eliminating switching charges.
A headline detail deserves attention: the Commission’s explainer says the Data Act will entirely remove switching charges (including data egress fees) from 12 January 2027. That date signals more than consumer friendliness. It indicates a future where businesses—and eventually individuals—can treat cloud providers less like landlords and more like vendors.
12 January 2027
European Commission explainer: date when the EU Data Act will entirely remove switching charges, including data egress fees.
What regulation can and can’t do
Policy can lower the cost of leaving. It can require clearer interfaces and more standardized portability. It cannot guarantee that a tool will still function during the next outage.
Local-first, by contrast, tries to make the “leave” button less dramatic. If you already have a complete local copy, switching becomes an operational decision rather than a crisis. Regulation and product architecture end up pushing in the same direction: reduce the penalties for mobility.
Local-first, by contrast, tries to make the “leave” button less dramatic. If you already have a complete local copy, switching becomes an operational decision rather than a crisis. Regulation and product architecture end up pushing in the same direction: reduce the penalties for mobility.
Editor’s Note
Regulation can make switching cheaper and cleaner, but it can’t make cloud dependence feel less brittle during an outage. Architecture can.
Real-world stress tests: what happens when the cloud goes down
Local-first arguments can sound abstract until you map them onto a familiar day of work. Take the Reuters-reported 2025 outages as case studies—not to single out one vendor, but to illustrate the consequences of centralization.
Case study: Microsoft 365 outage (Oct. 9, 2025)
Reuters reported that Microsoft attributed the issue to a misconfigured portion of network infrastructure in North America, with Downdetector peaking around 17,000 user reports. For many teams, Microsoft 365 is not a single app; it’s the spine connecting email, documents, calendars, and collaboration.
A local-first alternative doesn’t prevent an outage. It changes the failure mode. If a document editor remains usable offline with local storage and background sync, a network incident becomes a delay in sharing, not a halt in writing.
A local-first alternative doesn’t prevent an outage. It changes the failure mode. If a document editor remains usable offline with local storage and background sync, a network incident becomes a delay in sharing, not a halt in writing.
Case study: Azure outage (Oct. 29, 2025)
Reuters reported the Azure disruption lasted more than eight hours, affecting varied industries and peaking at over 18,000 complaints. Eight hours is long enough to turn a minor dependency into a major operational disruption.
Local-first tools won’t save every system—many businesses rely on cloud infrastructure for far more than documents. Still, for knowledge work, the architecture choice matters. When “create” and “edit” require permission from a distant service, outages become existential. When “create” and “edit” happen locally, outages become inconvenient.
Local-first tools won’t save every system—many businesses rely on cloud infrastructure for far more than documents. Still, for knowledge work, the architecture choice matters. When “create” and “edit” require permission from a distant service, outages become existential. When “create” and “edit” happen locally, outages become inconvenient.
Failure mode: cloud-first vs. local-first during an outage
Before
- Create/edit requires server access
- sharing and writing both halt
- outage becomes existential
After
- Create/edit happens locally
- sharing pauses
- outage becomes a sync delay
What local-first means for teams, creators, and IT buyers
Local-first isn’t a magic upgrade. It’s a different set of tradeoffs, and the value depends on what kind of work you do.
Practical takeaways for everyday users
If you write, design, research, or manage projects, local-first tools tend to deliver benefits you can feel immediately:
- Fewer hard stops: you can keep working during connectivity problems.
- Faster interaction: local reads and writes are often quicker than server round trips.
- More predictable access: your archive remains available even if a service is degraded.
The right mental model: local-first is like carrying your own library rather than borrowing every book from a single building across town.
- Fewer hard stops: you can keep working during connectivity problems.
- Faster interaction: local reads and writes are often quicker than server round trips.
- More predictable access: your archive remains available even if a service is degraded.
The right mental model: local-first is like carrying your own library rather than borrowing every book from a single building across town.
Implications for collaboration and governance
For teams, the big question becomes “How does sync behave under stress?” A local-first system has to be honest about:
- Conflict resolution: what happens when two people edit the same item offline?
- Security model: do users hold keys, or does the service?
- Recovery: can an employee restore data after device loss without a help desk nightmare?
IT buyers may find that local-first reduces some centralized risks while introducing a new governance challenge: data exists on endpoints. That may require stronger device management, better backup policies, and clearer guidance around key custody.
- Conflict resolution: what happens when two people edit the same item offline?
- Security model: do users hold keys, or does the service?
- Recovery: can an employee restore data after device loss without a help desk nightmare?
IT buyers may find that local-first reduces some centralized risks while introducing a new governance challenge: data exists on endpoints. That may require stronger device management, better backup policies, and clearer guidance around key custody.
A fair counterpoint: centralization is sometimes the point
Cloud-first systems didn’t win by accident. A single server as the source of truth can simplify auditing, compliance, and administration. It can make collaboration trivial. It can reduce data leakage to unmanaged devices—at least in theory.
Local-first advocates need to meet that argument directly. The strongest case for local-first isn’t “cloud is bad.” The strongest case is that dependency should be optional—and that modern collaboration should not require users to rent access to their own work.
Local-first advocates need to meet that argument directly. The strongest case for local-first isn’t “cloud is bad.” The strongest case is that dependency should be optional—and that modern collaboration should not require users to rent access to their own work.
Local-first tradeoffs for organizations
Pros
- +Keeps work usable offline
- +reduces hard stops during outages
- +speeds up everyday interactions
- +can improve user control (sometimes keys)
Cons
- -Puts more data on endpoints
- -increases backup/recovery responsibility
- -introduces merge/conflict edge cases
- -can complicate governance
Conclusion: the cloud can remain—without remaining the boss
Local-first software is not a rejection of modern computing. It’s a refusal to accept that “modern” means fragile. Outages like the Reuters-reported Microsoft 365 and Azure incidents in October 2025 did not create the problem, but they made it plain: the more we centralize everyday tools, the more we normalize helplessness.
The local-first movement—shaped by Ink & Switch thinkers such as Peter van Hardenberg and Martin Kleppmann, and enabled by ideas like CRDTs—offers a design alternative: keep a full working copy on the device, sync when possible, and treat the network as a convenience rather than a constant requirement.
Policy is also nudging the market toward mobility. The EU Data Act’s plan to remove switching charges, including egress fees, from 12 January 2027 is a clear statement that lock-in is no longer culturally or politically palatable.
The deeper appeal of local-first is less technical than philosophical: it treats the user as a participant, not a tenant. The cloud can still do what it’s good at—sharing, collaboration, redundancy—without becoming the authority that decides whether your workday gets to continue.
The local-first movement—shaped by Ink & Switch thinkers such as Peter van Hardenberg and Martin Kleppmann, and enabled by ideas like CRDTs—offers a design alternative: keep a full working copy on the device, sync when possible, and treat the network as a convenience rather than a constant requirement.
Policy is also nudging the market toward mobility. The EU Data Act’s plan to remove switching charges, including egress fees, from 12 January 2027 is a clear statement that lock-in is no longer culturally or politically palatable.
The deeper appeal of local-first is less technical than philosophical: it treats the user as a participant, not a tenant. The cloud can still do what it’s good at—sharing, collaboration, redundancy—without becoming the authority that decides whether your workday gets to continue.
T
About the Author
TheMurrow Editorial is a writer for TheMurrow covering trends.
Frequently Asked Questions
What does “local-first” mean in practice?
Local-first means the app keeps a complete, usable copy of your data on your device, so you can work even with no internet. Sync happens in the background when a connection returns. The server can still support collaboration and multi-device use, but it stops being the only place your data lives.
Is local-first the same as offline-first?
Offline-first is a big part of local-first, but local-first is broader. It aims for offline capability and user control, including reducing reliance on a server as the single source of truth. Many local-first tools still offer cloud collaboration; they just don’t require it for basic functionality.
Does local-first mean abandoning the cloud?
No. Local-first advocates often emphasize “local-first, not local-only,” a point also reflected in WIRED’s coverage of the movement. Cloud services can still provide sharing, backup, and collaboration. The difference is that the app should remain useful when the cloud is slow or unavailable.
Why are people talking about cloud fragility now?
Because outages increasingly interrupt normal work at scale. Reuters reported a Microsoft 365 outage on Oct. 9, 2025 with Downdetector peaking around 17,000 reports, and an Azure outage on Oct. 29, 2025 lasting over eight hours, with complaints peaking over 18,000. Incidents like these make centralized dependency visible.
What are CRDTs, and why do they matter for local-first?
CRDTs (Conflict-Free Replicated Data Types) are a technique that allows multiple devices to edit data independently and later merge changes reliably. WIRED likened the merge behavior to Git and noted CRDTs were fleshed out in academic work around 2011. They help make offline-friendly collaboration practical.
How does the EU Data Act relate to local-first software?
They address different layers of the same frustration: lock-in. The European Commission’s explainer on the EU Data Act describes measures to reduce barriers to switching cloud services, including removing switching charges such as egress fees from 12 January 2027. Local-first reduces lock-in by design, because users keep workable copies locally.
