Your App Shouldn't Need the Internet to Do Its Job

I've been thinking about offline-first architecture differently lately.

Not as an "offline mode" that you add when the application is almost finished.

But as a decision you make before you start building.

Because if the application depends on the internet for every important action, what happens when the internet disappears?

For some users, that's not a theoretical problem.

A clinic can lose connectivity.

A field worker can have no signal.

A power outage can take the network down.

And the user's work still needs to continue.

Offline mode isn't the same as offline-first

An application with offline mode usually starts with an online-first architecture.

When the connection disappears, it reacts:

• Show cached data
• Disable some features
• Display an offline message
• Wait for the connection to return

The internet is still the foundation.

Offline-first is different.

The application is designed to work locally first.

Data is written locally. The UI reads from local storage. The cloud becomes something the application synchronizes with when connectivity is available.

That's a very different architecture.

Aafiyat: SQLite first, Supabase later

I'm building Aafiyat as a clinic management system for private practices.

One of the requirements was simple:

A doctor should be able to continue working even when the internet isn't available.

Aafiyat is an Electron application using SQLite for local storage.

Patient records, consultations, prescriptions and billing information are saved locally first.

Then the application creates a synchronization job.

When connectivity returns, the queued data can be synchronized with Supabase.

So instead of:

User → API → Database

the important part of the application works more like:

User → SQLite
          ↓
      Sync Queue
          ↓
       Supabase

The user's save operation doesn't need to wait for the network.

That's the part I care about most.

The Nankana Home Care PWA

I'm applying the same thinking to another project: Nankana Home Care.

The platform includes a PWA for medical assistants who may need to record patient information without an internet connection.

Here I'm using IndexedDB for local storage.

Data can be queued locally and synchronized with Supabase when connectivity becomes available.

The implementation is different from Aafiyat, but the principle remains the same:

Do the user's work locally. Synchronize in the background.

Then comes the difficult part: synchronization

This is where offline-first gets complicated.

Saving something locally is easy enough.

Keeping local and server data consistent is harder.

What happens if:

• A request fails?
• The same record changes on two devices?
• A record is deleted while offline?
• The application closes before synchronization?
• The network disappears halfway through a sync?

You need answers to these questions before relying on the architecture.

In Aafiyat, I'm using a sync_queue with retry handling.

For conflicts, I'm using a last-write-wins approach based on updated_at.

It's a deliberate trade-off for the workflow I'm building.

There isn't one conflict-resolution strategy that fits every application.

Not every app needs this

I don't think every application should become offline-first.

A simple landing page doesn't need it.

A basic marketing website probably doesn't need a local database and sync system.

But if the application is being used for important work in an environment with unreliable connectivity, the calculation changes.

For example:

• Clinics
• Pharmacies
• Field services
• POS systems
• Local businesses
• Applications used in areas with inconsistent connectivity

In those cases, "the internet is temporarily unavailable" shouldn't automatically mean "the application can't do its job."

The trade-off

Offline-first adds complexity.

You have to think about local storage, synchronization, retries, conflicts, deletes and data consistency.

That's more work for the developer.

But the result can be software that keeps working when the network doesn't.

For the projects I'm building, that's an important trade-off.

I don't want to design software for an ideal environment.

I want to design it for the environment where the user actually works.

Offline-first isn't a feature. It's an architecture decision.