Working in the oil and gas industry presents unique challenges that most web developers never encounter. During my time at Key Energy Services, I led a team building a large-scale ERP solution where one requirement stood out: the app had to work when there was no internet connection.

The Connectivity Challenge

Oil fields aren't known for their reliable internet. Workers need access to critical systems whether they're in a remote well site with spotty cellular coverage or in an office with full broadband. This reality forced us to fundamentally rethink how we approached data synchronization and application architecture.

Architecture Decisions

We built the system using Ruby on Rails for the backend API, Meteor for real-time capabilities, and Backbone.js for the frontend. The key was implementing a robust offline-first architecture:

// Simplified example of our sync strategy
class DataSyncManager {
  constructor() {
    this.localDB = new LocalDatabase();
    this.syncQueue = [];
    this.isOnline = navigator.onLine;
  }
 
  async saveData(entity, data) {
    // Always save locally first
    await this.localDB.save(entity, data);
 
    if (this.isOnline) {
      try {
        await this.syncToServer(entity, data);
      } catch (error) {
        this.queueForSync(entity, data);
      }
    } else {
      this.queueForSync(entity, data);
    }
  }
 
  async syncToServer(entity, data) {
    const response = await fetch(`/api/${entity}`, {
      method: 'POST',
      body: JSON.stringify(data)
    });
 
    if (!response.ok) throw new Error('Sync failed');
  }
}

Conflict Resolution

The hardest part wasn't storing data locally. It was handling conflicts when multiple users edited the same record offline. We implemented a last-write-wins strategy with timestamp-based conflict detection, but also built manual conflict resolution tools for critical data.

Testing Offline Scenarios

Testing offline functionality required discipline. We used Docker to create network conditions that simulated various connectivity scenarios - from complete offline to slow 2G connections. This helped us catch edge cases before they reached production.

# Example Docker network throttling
docker run --network=slownet \
  --cap-add=NET_ADMIN \
  my-erp-app
 
# In another container, throttle the network
tc qdisc add dev eth0 root netem delay 2000ms 200ms

Key Takeaways

Building offline-first applications taught me several valuable lessons:

1. Local-first is resilient-first: By treating the local database as the source of truth and syncing as a background operation, users never felt blocked by connectivity issues.

2. Progressive enhancement matters: Critical features worked offline, while nice-to-haves required connectivity. This prioritization was essential.

3. Sync is hard: Implementing reliable bidirectional sync is more complex than most developers anticipate. Budget time accordingly.

4. User feedback is critical: Clear indicators of online/offline state and pending syncs helped users trust the system.

The principles I learned building ERP systems for oil and gas have served me well in other domains. Any application dealing with unreliable connectivity - whether it's field service, healthcare, or mobile-first apps - benefits from an offline-first approach.

In an era where we assume constant connectivity, building for the offline case makes applications more robust for everyone.