← Back to selected work

Deliveries don't stop where the signal ends.

I led the re-engineering of a mobile inventory and delivery app, helping truck drivers complete their work in areas with unreliable connectivity.

Lead Developer
Rococo Global Technologies Corporation
React Native · SQLite · PHP · MySQL · REST APIs · Offline Sync
MARTS mobile application interface
MARTS — inventory pickups and store deliveries for San Miguel Corporation's drivers.

The challenge: a route can outlast its connection

Drivers used MARTS to manage inventory pickups and deliveries to stores. The existing workflows struggled in low-connectivity areas, delaying updates and leaving delivery confirmations unrecorded.

The re-engineering work needed to address that interruption alongside the app's existing database and business logic. Completing a delivery had to remain possible without a continuous network connection.

What I owned

As lead developer during the re-engineering, I owned the offline-mode architecture, database optimization, and refactoring of the core business logic.

Delivery work without a continuous connection

I designed and implemented offline sync so drivers could complete deliveries in low-signal areas, with delivery data synchronized after reconnection.

Faster inventory access

I reworked database schemas and queries in the legacy inventory and delivery modules to improve query performance.

Business logic ready for further changes

I refactored core application logic to make the existing modules easier to maintain and support new operational requirements. Connected routes retained real-time delivery tracking.

A workflow that follows the driver

The user-facing flow connects work completed without a signal to updates shared when connectivity returns.

  1. Complete the delivery

    The driver can finish delivery work while offline.

  2. Reconnect

    The app synchronizes delivery data when a connection is available again.

  3. Continue tracking

    Connected routes support real-time delivery updates.

A repeated request should not become a second delivery

Reconnecting introduces another problem: a timeout can leave the app unsure whether the server saved a request. A retry, a second tap, or another reconnection event can send the same payload again. I designed the sync flow to handle those repeated attempts.

Give records an identity before they reach the server

The React Native app generates a unique ID when a record is created. That ID is used in both local SQLite storage and the backend, so creating a record offline does not depend on the server assigning an auto-incrementing ID.

Remember which requests have already been processed

Each sync request carries an idempotency key: a token that lets the backend recognize another attempt at the same operation. Within the key's retention window, a completed request returns its cached response without repeating the database writes. Duplicate requests arriving while the original is still running are prevented from executing concurrently.

Keep pending work in a persistent queue

Pending changes are stored in a dedicated SQLite sync queue. Requests run sequentially for each resource, and each queue item has an explicit status. An item already syncing cannot be picked up again when another reconnection event fires.

  1. PENDING
  2. SYNCING
  3. SYNCED / FAILED

The design protects both sides of the connection: the queue prevents duplicate processing on the device, and the backend recognizes repeated requests that still reach it.

Merge the fields that changed

I used field-level merging for updates: syncing a patch containing the changed fields instead of replacing the entire record. This lets changes to different fields coexist without an older offline copy overwriting unrelated updates.

Results

MARTS supported delivery work in no-signal zones, with offline capability built into the production application. The re-engineering also improved inventory query performance and the maintainability of its core modules.

deliveries completable offline
100%deliveries completable offline
faster inventory queries after re-engineering
~3xfaster inventory queries after re-engineering
lost confirmations from dead zones after rollout
0lost confirmations from dead zones after rollout

Building software for work in the field?

I'm open to roles involving mobile applications, backend systems, and enterprise workflows.

Let's talk →