Offline-first or always online: what is left of an app without a connection?

A Notion page can be downloaded before going offline. That does not mean its subpages or an entire database come with it. According to Notion's current offline guidance, pages must be selected individually, while an offline database includes the first 50 rows of its first view by default. If the task you need is further down, the word “offline” does not make it available.

Google Maps draws a different boundary. A downloaded area can guide a driver when the entire route fits within it. Without a connection, however, traffic information and alternative driving routes disappear, and transit, cycling, and walking directions are unavailable.

Both products work offline in a meaningful sense. But the useful part is not the presence of a local database. It is the work a person can actually finish. That question belongs before the choice of offline-first, not after installing a synchronization package.

Keeping an app connected to a server is not inherently a bad architectural choice either. Collaborative editing, booking a scarce resource, or authorizing a payment may require a shared, current decision. The mistake is to extend that requirement to actions for which an immediate server response adds nothing.

The document is there. Is the work?

Comparing Notion with Obsidian is useful not because one has the “correct” architecture, but because they make different promises about a person's data.

Obsidian stores notes as local files. Reading and editing the files already on a device does not require a network connection; synchronization across devices is a separate choice. That gives the owner more independence, but also puts part of the responsibility for preservation on the owner or the chosen service. Obsidian itself warns that sync is not a backup.

Notion offers a shared workspace shaped by pages, database views, permissions, and other people's changes. An offline page can be edited, but access to adjacent material depends on what has reached the device. Permissions and some advanced features still need a connection. “Download everything” is not an obvious fix: a workspace can be large, while its structure and access rights can change.

That suggests a bounded product hypothesis. Instead of asking someone to save a single page, an app could help them prepare one project for offline work: the relevant subpages, a chosen task view, and associated files within a visible size limit. Before the connection disappears, it should also show what will not be available. The person could then check whether the task is ready, rather than guess which part of the workspace the app considers local.

This would cost more than a new toggle. More data would live on the device. The app would need to track changes to the selected material, limit its size, and handle pages whose permissions change. That is not a claim that Notion overlooked these concerns. In its account of building offline support, the team describes why pages are kept locally and why repeatedly polling every page would not scale. Expanding the task that works offline expands that responsibility too.

For personal notes that should remain available at any time, Obsidian's local-file model has a clear appeal. For a team that needs shared structure and access control, Notion gains something different from the server. Making both products “fully local” would not improve them in the same way. Asking whether a specific task survives a lost connection is more likely to reveal a useful change.

The map is saved. The road conditions are not.

Google Maps exposes another split. The downloaded road network can support a driving route. Traffic changes in real time, and alternative routes are not available in its offline mode. A saved map therefore cannot support the same routing decision as a connected one.

Consider a field-service app used by technicians visiting several sites in a day. The addresses, work orders, equipment diagrams, and map areas can be known before the first visit. If the app fetches each order only when it is opened, poor reception stops a technician before any live information is actually needed. Preparing the day's work on the device could keep the assignments and route accessible. Promising an accurate arrival time from an old traffic snapshot would be the opposite error.

In that product, the useful check is whether the whole day is ready, not whether at least one map has been downloaded. Are all sites and orders available? Does the driving route fit inside the downloaded areas? When were those areas updated, and which guidance will disappear offline? Google's help page establishes the route and mode limitations. The proposed readiness check belongs to the hypothetical field-service product; it is not a claim about a missing Google Maps feature.

Nor does this justify copying an unlimited map to every device. Offline areas take space and need updates. Google also notes that downloads are unavailable in some regions because of contractual and other constraints. The engineering task is to select the data needed for a defined job and make the remaining dependence on live information explicit.

Different parts of one workday can follow different rules. A work order may open from local storage. Driving directions may use a prepared map. Traffic-based arrival estimates may appear only when connected. These are not three reasons to impose one universal cache policy, or to make every screen wait for the server.

The card payment was recorded. Was it approved?

At a restaurant, the connection fails after an order has been entered. Must service stop? Must card payments stop? Or can the restaurant continue and settle the risk later? Treating all three questions as “does the POS work offline?” hides the decision that matters.

Toast's outage guidance allows its POS to take card payments in offline mode when background processing is enabled. The transaction is stored on the device and submitted for authorization after connectivity returns. A card can then be declined after the guest has left; Toast says the restaurant bears the risk. Its operating guidance distinguishes a pending authorization from an approved one on the guest receipt.

That is more instructive than the blanket rule “payments must always be online.” A real product allows service to continue, but deferred authorization does not turn uncertainty into a completed payment. A busy restaurant facing a short outage and a business selling a costly one-off item face different costs when a sale stops—and when it fails after the customer leaves.

The product decision is therefore a policy, not a global offline-first switch. When may staff accept a card without authorization? What transaction limit is acceptable? Who can override it, what does the operator see while payments are pending, and who handles a later decline? Toast documents a transaction limit and an option to disable offline card acceptance. The example illustrates why those controls matter; it does not propose adding features the product already has.

Requiring a live decision for a payment may still be the safer choice. It does not follow that every interaction with the order screen must make a network round trip. Editing an order or moving through the menu can remain responsive locally. The online boundary belongs at the point where authorization is required, not at every intermediate gesture.

“Online product” does not mean “every pixel over the network”

Cloud editors have good reasons to keep the server close to the work. Figma describes real-time collaboration as central to its product. During a disconnection, a designer can continue editing pages already loaded in the current session, but cannot fetch new library components, see collaborators' changes, or access version history. Figma does not call this full offline support.

A prepared file snapshot might help a designer continue individual work away from a connection. That is a product hypothesis, not an account of Figma's roadmap. It has limits: shared libraries and colleagues' edits will continue to change, while the local copy will need storage and merging rules. Better solo work does not automatically mean better live collaboration.

Still, a server-centered product does not need to wait for a response whenever an object moves by one pixel. The ability to keep editing an already loaded page during a disconnection shows the distinction: the interface can react locally while confirmation and shared state catch up. Depending on the network for shared state is not the same as making each movement a network request.

Constant communication also has a physical cost. Android's guidance warns that frequent network activity can keep the radio active and drain the battery. The reverse slogan, “offline-first always saves energy,” is no more reliable: Flutter's guidance notes the cost and constraints of continuous background synchronization. Energy savings cannot be assigned to an architectural label. They have to be measured for a real workload, including request frequency, download volume, and background activity.

What to examine in your own product

After these examples, “should we build offline-first?” is too broad a question for a single answer. Start with a few important user jobs. For each one, name the result the person considers complete, then walk through the job with a normal connection, a poor connection, and no connection.

If all value disappears offline, that does not by itself justify a local database. The product may genuinely sell access to a live shared state. But if a server response is required even to read an assignment already received, write a draft, or return to a personal note, the dependency may reflect an implementation habit rather than a product need.

A compact review matrix is enough to make the trade-off concrete:

Question	What it changes
Which work must continue without a connection?	Defines the local data and behavior, rather than a generic “offline” checkbox.
How old may the data be?	Separates a useful local result from a misleading claim of freshness.
What if a deferred action is rejected later?	Exposes the cost to the user and the business.
What is lost when the device fails or is replaced?	Tests recovery, not merely synchronization.
What do local copies and continuous exchange cost?	Brings storage, updates, network use, battery, and maintenance into the decision.

The answers may differ between two screens in the same app. A complex product does not improve just because offline-first is applied everywhere. An always-online design is not justified simply because a server exists. An architectural cost is worth paying only when it buys a property of the product that can be named and checked.

This analysis relies on published product behavior and bounded design hypotheses, not access to these products' source code or internal metrics. The proposals to prepare a project, a field-service workday, or a file snapshot are not claims about the plans of Notion, Google, or Figma. No Flutter prototype or measurements of latency, battery use, failure rates, or server cost were performed for this article. Those checks would be needed before adopting a similar design in a particular app.

---

More engineering articles are available at ArkTelos Lab. For the ecosystem and its tools, visit the official ArkTelos website.

Telegram: ArkTelos Lab EN | ArkTelos Lab RU | ArkTelos EN | ArkTelos RU.