MARTS · San Miguel Corporation
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.
- My role
- Lead Developer
- Delivered at
- Rococo Global Technologies Corporation
- Technology
- React Native · SQLite · PHP · MySQL · REST APIs · Offline Sync

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.
01
Complete the delivery
The driver can finish delivery work while offline.
02
Reconnect
The app synchronizes delivery data when a connection is available again.
03
Continue tracking
Connected routes support real-time delivery updates.
Engineering decisions
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.
- PENDING
- SYNCING
- 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 →