Why I’m Building More Local-First Software

Modern applications often follow the same pattern:

Open the app → connect to the internet → send data to a server → wait for a response → continue working.

That model works extremely well for many products, but I think developers should also spend more time thinking about another approach:

What if the application could do much more without an internet connection?

That question is one of the reasons I’ve become increasingly interested in local-first software.

What Does Local-First Mean?

A local-first application keeps the user's important data and core functionality available on the device whenever possible.

The internet can still be useful, but it doesn't necessarily have to be a requirement for the basic experience.

For example, imagine a note-taking application.

A traditional cloud-first workflow might look like this:

User
  ↓
Application
  ↓
Internet
  ↓
API Server
  ↓
Database
  ↓
Response
  ↓
Application

A local-first application can instead work like this:

User
  ↓
Application
  ↓
Local Database

Synchronization can happen later when connectivity is available.

Local Database
      ↓
   Sync Engine
      ↓
    Internet
      ↓
  Cloud Backup

This changes the architecture significantly.

Offline Shouldn't Always Mean Broken

One of the biggest problems with internet-dependent applications is that users often lose functionality when connectivity disappears.

Maybe the connection is slow.

Maybe the user is traveling.

Maybe the server is temporarily unavailable.

Maybe the device is simply in an area with poor network coverage.

The application shouldn't necessarily become useless because of that.

For many types of software, users should still be able to:

• Create data
• Edit existing data
• Search local information
• Read previously stored content
• Organize their files
• Run supported computations
• Continue working

The application can synchronize later.

Local Storage Is Becoming More Important

Local storage doesn't have to mean saving everything into random files.

Modern applications can use structured local databases and storage systems.

Depending on the platform, developers can choose technologies such as:

• SQLite
• Room
• Core Data
• IndexedDB
• Realm
• Local JSON or structured files
• Platform-specific key-value storage

For an Android application, for example, a local database can become the source of truth for much of the application's everyday operation.

A simplified architecture might look like:

                ┌───────────────────┐
                │    UI Layer       │
                └─────────┬─────────┘
                          │
                ┌─────────▼─────────┐
                │  ViewModel /      │
                │  Application Logic│
                └─────────┬─────────┘
                          │
                ┌─────────▼─────────┐
                │   Repository      │
                └──────┬─────┬──────┘
                       │     │
              ┌────────▼─┐ ┌─▼─────────┐
              │Local DB  │ │ Sync/API  │
              └──────────┘ └───────────┘

The local database handles everyday usage.

The synchronization layer handles communication with remote services.

That separation can make the architecture easier to reason about.

Local-First Doesn't Mean Cloud-Never

This is an important distinction.

I'm not arguing that cloud services are bad.

Cloud infrastructure is incredibly useful.

It can provide:

• Backup
• Cross-device synchronization
• Collaboration
• Remote access
• Account management
• Sharing
• Large-scale processing

The interesting question is not:

"Should I use cloud or local storage?"

A better question is:

"Which parts of my application actually need the cloud?"

That shift in thinking can lead to much better architecture.

Privacy Is Another Major Advantage

When an application keeps data on the user's device, fewer things need to leave that device.

That can be valuable for privacy-sensitive applications.

Consider a personal application that stores:

Notes
Tasks
Documents
Personal Preferences
Search History
Private Projects

A developer could design the application so that the basic functionality works entirely locally.

Cloud synchronization could become an optional feature rather than a mandatory requirement.

That gives users more control over their data.

Local-First + AI

This becomes even more interesting when AI enters the picture.

Many AI applications currently depend heavily on remote APIs.

The architecture often looks like:

User Input
    ↓
Application
    ↓
Remote AI API
    ↓
Model
    ↓
Response

But local AI can change the design.

A local-first AI application could look like:

User Input
    ↓
Application
    ↓
Local Model
    ↓
Response

And potentially:

             ┌───────────────┐
             │   User Input  │
             └───────┬───────┘
                     │
             ┌───────▼───────┐
             │ Local AI Model│
             └───────┬───────┘
                     │
             ┌───────▼───────┐
             │ Local Storage  │
             └───────────────┘

                     │
              Optional Sync
                     │
             ┌───────▼───────┐
             │ Cloud Services │
             └───────────────┘

This opens up interesting possibilities for privacy-focused AI tools.

Imagine an assistant that can search your own documents without automatically uploading everything to a third-party server.

That's a very different product philosophy.

The Challenges Are Real

Local-first development isn't automatically easier.

There are several difficult engineering problems.

Synchronization

Suppose the same document changes on two devices.

Device A:

Title = "My Project"

Device B:

Title = "My Open Source Project"

Now the application needs a strategy for resolving the conflict.

Simple applications may use:

Last Write Wins

More advanced systems can use conflict-free data structures or domain-specific merge strategies.

Storage Limits

A device has finite storage.

If an application stores everything locally, the developer has to think carefully about:

• Database size
• Cache size
• Media files
• Cleanup
• Backups
• Import/export

Device Loss

Local-first systems also make backups important.

A user shouldn't lose years of work simply because their phone is lost or damaged.

That's why an architecture can provide:

Local Data
    +
Optional Encrypted Backup
    +
Optional Cross-Device Sync

Security

Local data must still be protected.

Developers need to consider:

• Encryption
• Authentication
• Secure key storage
• File permissions
• Database access
• Backup security

Local-first doesn't automatically mean secure.

Security still has to be designed.

A Good Architecture Is About Trade-Offs

There is no universal architecture that works for every application.

A real-time multiplayer game may require continuous network communication.

A financial service may depend heavily on remote systems.

A collaborative editor may need sophisticated synchronization.

But a personal notes app?

A task manager?

A local code-search tool?

A document organizer?

An offline AI assistant?

Those applications may benefit substantially from a local-first approach.

What I'm Interested in Building

My own development interests increasingly revolve around applications that prioritize:

Local Data
      ↓
Offline Functionality
      ↓
Fast Interaction
      ↓
Optional Synchronization
      ↓
Optional Cloud Features

I'm particularly interested in combining this approach with:

• Android development
• Rust
• TypeScript
• Local databases
• AI
• Developer tools
• Offline search
• Open-source software

One project can start completely locally and later add cloud functionality without making the cloud the foundation of the entire experience.

What Developers Can Learn From This

The local-first mindset encourages developers to ask better architectural questions.

Instead of immediately asking:

"Which API should I use?"

Ask:

"Does this feature actually require an API?"

Instead of:

"Where should I store this?"

Ask:

"Who should own this data?"

Instead of:

"How can I make the application work online?"

Ask:

"How much of the application can continue working offline?"

Those questions can lead to simpler, more resilient software.

My Current Take

I don't think local-first software will replace cloud applications.

I think the two approaches can coexist.

The cloud is excellent for synchronization, collaboration, backups, remote processing, and large-scale infrastructure.

The local device is excellent for responsiveness, offline access, personal data, and immediate interaction.

The interesting architecture is often somewhere in the middle:

             ┌─────────────────┐
             │     User        │
             └────────┬────────┘
                      │
             ┌────────▼────────┐
             │   Local App     │
             └───────┬─────────┘
                     │
          ┌──────────┴──────────┐
          │                     │
   ┌──────▼──────┐       ┌──────▼──────┐
   │ Local Data  │       │ Local AI /  │
   │             │       │ Processing  │
   └──────┬──────┘       └──────┬──────┘
          │                     │
          └──────────┬──────────┘
                     │
              Optional Sync
                     │
             ┌───────▼───────┐
             │ Cloud Services │
             └───────────────┘

For me, that is the most exciting part.

Build for the device first. Use the cloud when it genuinely adds value.

That principle can produce software that feels faster, works in more situations, and gives users more control over their own data.

---

I'm curious what other developers think about this architecture.

Do you prefer cloud-first applications, local-first applications, or a hybrid approach?

Share your experience in the comments.

You can also find my open-source work on GitHub:

https://github.com/sanskarIN

And my personal developer website:

https://sanskarin.github.io