The Internet Blackout Playbook: What Iran's 13-Day Shutdown Teaches SaaS About Offline-First Architecture

On March 1, 2026, Iran's government flipped the switch. International internet traffic dropped to near zero across the country. Eighty-eight million people lost access to the global web.

Thirteen days later, it's still off.

The humanitarian consequences are severe and well-documented -- disrupted medical supply chains, families unable to contact relatives abroad, journalists cut off from the outside world. Organizations like Access Now and NetBlocks have tracked the shutdown in real time, and the human cost is staggering.

But buried in the crisis is a technical story that every software engineering team should study. Because when the internet disappeared, some apps kept working. Most didn't. And the line between them wasn't luck or geography -- it was architecture.

The Kill Zone: What Happens When SaaS Loses the Network

The modern SaaS stack is, architecturally, a thin client connected to a fat server. Your browser or mobile app is a rendering layer. The data lives in the cloud. The business logic runs on someone else's computer. When the network goes away, the application doesn't degrade gracefully. It ceases to exist.

Here is what happened to common SaaS categories during the Iran shutdown, based on reports from Internet Freedom organizations and user accounts compiled by researchers at the Oxford Internet Institute:

The pattern is stark. Every product built on the assumption that the server is always reachable failed immediately or within hours. Every product that stored data locally and ran logic on-device kept working indefinitely.

This isn't just an Iran problem. Submarine cable cuts in the Red Sea disrupted internet access across East Africa for weeks in early 2025. Cloudflare's outage reports logged 14 significant regional connectivity events in 2025 alone. Hurricane Helene knocked out internet for parts of the southeastern United States for 9 days in October 2025. The question isn't whether your users will lose connectivity. It's when, and what they'll experience when they do.

The Offline-First Survival Kit

The apps that survived Iran's blackout share a common set of architectural patterns. None of these patterns are new -- they've been advocated by the local-first software movement since Ink and Switch published their seminal paper in 2019. What the Iran shutdown provides is the most dramatic real-world stress test these patterns have ever received.

Pattern 1: Local-First Data Storage

The foundational principle is simple: the user's data lives on the user's device. The cloud is a sync target, not the source of truth.

In practice, this means using on-device databases -- SQLite for mobile apps, IndexedDB or OPFS (Origin Private File System) for web apps -- as the primary data store. The application reads from and writes to the local database. A sync engine handles replication to the server when connectivity is available.

Obsidian, the note-taking app that has built a devoted following among developers and researchers, exemplifies this pattern. Every note is a Markdown file stored in a local folder on the user's device. Obsidian Sync is an optional paid service that replicates notes across devices, but the core product works perfectly without it. During the Iran shutdown, Obsidian users retained access to every note they'd ever written. Notion users stared at loading spinners.

The technical implementation is more nuanced than "just use SQLite." You need:

• A schema design that supports offline reads for your core use cases
• Write-ahead logging to prevent data corruption during unexpected shutdowns
• Storage management to handle device space constraints
• Migration strategies that work without server coordination

PowerSync, one of the leading sync engine startups, reported a 340% increase in inbound inquiries in the first week of the Iran shutdown. Their pitch -- Postgres on the server, SQLite on the device, real-time sync between them -- suddenly had an urgency it hadn't before.

Pattern 2: Client-Side Business Logic

Storing data locally is necessary but not sufficient. If the application logic runs on the server, local data is just a cache that can't be meaningfully interacted with.

True offline-first apps run their core business logic on the client. Filters, sorts, searches, calculations, validations -- all of these execute against the local database without any server round-trip.

This is where most SaaS companies hit their first architectural wall. Server-side business logic isn't just a convenience; it's often a security boundary. Pricing calculations, access control checks, and data validation rules live on the server because putting them on the client means they can be inspected and potentially bypassed.

The offline-first answer is a layered trust model. Non-sensitive logic (search, filtering, formatting, local calculations) runs on the client. Sensitive logic (payment processing, access control, audit logging) is queued for server-side execution when connectivity returns. The app clearly communicates which actions are confirmed and which are pending.

Linear, the project management tool that has become the default for high-velocity engineering teams, implements this pattern effectively. You can create issues, update statuses, add comments, and reorganize projects while completely offline. Linear's sync engine queues these operations locally and replays them against the server when the connection returns. The UI distinguishes between synced and pending operations with subtle visual indicators.

Pattern 3: Conflict Resolution with CRDTs

The hardest problem in offline-first architecture isn't storage or business logic. It's what happens when two users edit the same data while both are offline, then reconnect.

Traditional approaches -- last-write-wins, manual conflict resolution, locking -- all break down in extended offline scenarios. Last-write-wins silently discards data. Manual resolution creates a backlog that grows quadratically with offline duration. Locking prevents any offline writes at all.

CRDTs (Conflict-free Replicated Data Types) solve this mathematically. A CRDT is a data structure with a merge function that is commutative, associative, and idempotent -- meaning edits can arrive in any order, be applied multiple times, and still converge to the same result on every device.

The two production-grade CRDT libraries that have emerged as industry standards are Yjs and Automerge. Both handle rich text, JSON-like documents, and array operations. Both have been battle-tested in collaborative editors serving millions of users.

Here is how a CRDT-based offline sync works in practice:

1. User A (offline) renames a task from "Design review" to "Design review -- Q2"
2. User B (offline) adds a comment to the same task
3. Both users reconnect
4. The CRDT merge function applies both operations without conflict -- the task is now named "Design review -- Q2" and has User B's comment
5. No manual resolution needed. No data lost.

For more complex conflicts -- two users editing the same paragraph of text simultaneously -- CRDTs handle character-level merging that produces intuitive results in the vast majority of cases.

Pattern 4: Opportunistic Sync with Queue-Based Architecture

The final pattern is how offline-first apps handle the transition between offline and online states. Rather than treating connectivity as binary (connected/disconnected), resilient apps implement an operation queue that continuously attempts to sync.

Every write operation is first committed to the local database, then added to a sync queue. A background process monitors connectivity and drains the queue when a connection is available. If the connection drops mid-sync, the queue picks up where it left off. Operations are idempotent, so replaying a partially-completed sync is safe.

This queue-based approach also handles degraded connectivity gracefully -- a situation far more common than total blackout. Users on slow, unstable, or throttled connections (common in many parts of the world, not just during government shutdowns) experience the app as responsive because all interactions hit the local database first.

Replicache, a sync framework used by several notable apps including Reflect and Shortcut, implements this pattern as a library. Their architecture uses a "client view" model where the server defines the authoritative state, but the client maintains a local fork that it can modify freely. When connectivity returns, the client rebases its local changes onto the server state -- a model deliberately inspired by Git's rebase operation.

The Business Case: Why "Our Users Have Internet" Is No Longer Sufficient

The most common objection to offline-first architecture is economic: "Our users are in the US/Europe. They have reliable internet. The engineering cost isn't justified."

This argument is weakening for three reasons.

First, the addressable market is shifting. The next billion SaaS users are disproportionately in regions with unreliable connectivity. India's internet penetration is 52% but connection quality varies enormously by region and time of day. Sub-Saharan Africa's mobile internet is growing at 15% annually but infrastructure remains inconsistent. Companies building exclusively for always-connected users are designing for a shrinking share of the global market.

Second, enterprise reliability requirements are escalating. Gartner's 2025 IT infrastructure survey found that 67% of enterprise IT leaders now include "offline capability" in their SaaS procurement evaluation criteria, up from 23% in 2022. The driver isn't internet shutdowns -- it's a post-pandemic recognition that field workers, manufacturing floor operators, and traveling executives need tools that work in elevators, on airplanes, and in areas with dead zones.

Third, the engineering cost has dropped dramatically. In 2020, building offline-first meant rolling your own sync engine -- a 6-12 month project for a senior team. In 2026, off-the-shelf solutions like PowerSync, ElectricSQL, Replicache, and Triplit have reduced the integration to 2-4 weeks for basic offline support. CRDT libraries have matured to the point where conflict resolution -- historically the hardest offline problem -- is a configuration choice rather than a research project.

The ROI calculation has flipped. For most B2B SaaS products, adding basic offline support is now cheaper than the revenue lost from a single enterprise deal that requires it.

The Implementation Playbook: Progressive Offline

You don't need to rebuild your entire application to add offline capability. The pattern that's emerging among teams adopting offline-first is progressive -- start with the highest-value offline use cases and expand from there.

Step 1: Identify Your Offline Core

Not every feature needs to work offline. Identify the 20% of your product that delivers 80% of user value, and focus offline support there.

For a project management tool, that's viewing tasks and updating statuses. For a CRM, it's accessing contact details and logging interactions. For a document editor, it's reading and editing existing documents. For a messaging app, it's reading recent messages and composing new ones (queued for send).

Step 2: Implement Service Workers for Asset Caching

The lowest-hanging fruit for web apps is a service worker that caches your application shell -- HTML, CSS, JavaScript, and static assets. This ensures the app loads even without a connection. Combined with a Web App Manifest, your SaaS product can be installed as a PWA (Progressive Web App) and launched from the home screen like a native app.

This single step takes a product from "shows a browser error page when offline" to "loads the UI and shows cached data." It's 1-2 days of engineering work for most React/Next.js applications.

Step 3: Add a Local Database Layer

Introduce a client-side database (IndexedDB via Dexie.js for web, SQLite for mobile) and replicate your most-accessed data into it. Configure your queries to read from the local database first, falling back to the server only for data that isn't cached locally.

ElectricSQL has gained traction for this step specifically because it syncs a subset of your Postgres database to SQLite on the client, using a declarative "shape" syntax to define what data each client receives. You keep your existing Postgres backend and add a local replica.

Step 4: Implement Optimistic Writes with Queue

Allow users to perform write operations against the local database, queuing mutations for server sync. Display pending operations with a visual indicator (a small sync icon, a subtle "pending" badge) so users understand the state of their data.

The critical detail: design your mutations to be idempotent. Use unique client-generated IDs for new records so that replaying a write operation doesn't create duplicates.

Step 5: Add Conflict Resolution for Collaborative Scenarios

If your product supports multiple users editing shared data, integrate a CRDT library for the data types most likely to produce conflicts. For text content, Yjs provides a drop-in solution. For structured data (JSON objects, arrays), Automerge handles merging automatically.

This step is only necessary for collaborative products. Single-user offline (e.g., a CRM where each rep manages their own contacts) can use simpler last-write-wins resolution with server timestamps.

What the Iran Shutdown Changes

The Iran blackout is not, by itself, a reason to rebuild your SaaS product. The vast majority of your users are probably not in Iran, and the specific scenario of a government-imposed total shutdown is, for most products, an edge case.

But the shutdown crystallizes a trend that has been building for years. Internet connectivity is not a binary condition. It exists on a spectrum -- from fiber-optic in a San Francisco office to intermittent 3G on a construction site in Lagos to satellite-only on a research vessel to zero during a natural disaster or government censorship event.

Products that treat connectivity as a spectrum -- degrading gracefully rather than failing totally -- serve a larger market, win more enterprise deals, and build deeper user trust. The Iran shutdown is the extreme end of the spectrum, but the engineering patterns that survive a 13-day blackout also deliver a better experience on a spotty airport WiFi connection.

The companies that understood this early -- Obsidian, Linear, Figma (which has been quietly building offline capabilities since 2024), and the growing ecosystem of local-first startups -- aren't building for government shutdowns. They're building for the real world, where internet access is messy, unreliable, and unevenly distributed.

The Architecture Decision You're Making Whether You Know It or Not

Every SaaS product has an implicit connectivity assumption baked into its architecture. Most products assume always-on broadband. This assumption was reasonable in 2015 when SaaS users were overwhelmingly knowledge workers in developed-market offices. It is increasingly unreasonable in 2026.

Iran's 13-day shutdown didn't create this problem. It revealed it -- with a clarity that 14 Cloudflare outage reports and a dozen submarine cable incidents couldn't match. Eighty-eight million people watched their cloud-dependent tools vanish overnight. The tools that survived weren't better marketed or better funded. They were better architected.

The offline-first patterns described here -- local data storage, client-side logic, CRDTs for conflict resolution, queue-based opportunistic sync -- are not bleeding-edge research. They are production-ready, well-documented, and increasingly affordable to implement. The sync engine ecosystem has matured to the point where adding meaningful offline support to an existing product is a quarter-long initiative, not a year-long rewrite.

The question is no longer "should we build offline support?" The question is "what happens to our users -- and our revenue -- the next time the internet goes away?" Because it will go away. Not everywhere at once. Not always for 13 days. But often enough, and in enough places, that the products built to handle it will have a meaningful competitive advantage over those that aren't.

The playbook is sitting right there in the wreckage of Iran's internet blackout. The only question is whether you read it before or after your users need it.