The trip happens in the field.
The system has to keep up.
A logistics operation is not confined to a browser. There is a driver using an app, location data being collected, trip information moving between devices and an operations team looking at the web panel.
The app must retain location data when connectivity drops and synchronize it with the backend when a connection is available. The dashboard uses that data to show the operation.
I designed the architecture.
And built the core.
My responsibilities covered the backend and data, GPS integration, web and mobile interfaces, and the app release.
What I took responsibility for
- Core architecture, APIs, data and Cloudflare/Supabase integration.
- Integration between the driver app and operations dashboard through the Core API.
- GPS SDK integration, investigation of offline behavior and batch synchronization.
- Technical diagnostics and route visualization improvements.
- Preparation and publication of the app for iOS and Android.
The structure behind
the product.
The map shows the main responsibilities and connections. Expand it to explore the flow, or select a layer to understand its role in the system.
Read the diagram as text
The driver app stores data locally in SQLite and sends batches to the Hono Core API. The Next.js panel and public trip view use the same backend. Core validates sessions through Supabase Auth, applies business rules and accesses PostgreSQL with PostGIS, private trip evidence in R2, and private profile documents in Supabase Storage. Arrows show selected requests and dependencies, not every network path.
Design for the device, not just the request.
The app separates screens from domain and integration logic. Local persistence uses SQLite/Drizzle, with a background location SDK and dedicated synchronization flows. Offline support does not make background execution unlimited: permissions, OS behavior and connectivity still matter.
A retry must not become another batch.
The backend identifies incoming GPS batches by clientBatchId and checksum. This allows retries to be handled as repeats rather than new evidence. The app and server must also agree on the batch state and ordering.
Keep business rules in the backend.
Routes validate input with Zod and call services; repositories handle persistence and mappers shape the response. The backend resolves organization context and authorization. GPS points are evidence; mileage uses the driver’s declared distance and odometer readings/photos.
Make the operation visible without exposing the files.
The panel consumes Core through TanStack Query. Trip evidence lives in private R2 storage, while avatars and driver documents use private Supabase Storage. Signed access and backend checks connect the interface to those files.
What I chose.
The trade-offs involved.
01Make synchronization idempotent.Resend without duplicating the evidence.
Design choice
Use a batch identifier and checksum when accepting GPS points. The transport can retry without treating each delivery as a new logical batch.
The trade-off
Idempotency needs a persistent contract: identity, conflict handling and application state have to stay coherent. It does not remove mobile OS and connectivity constraints.
02Separate GPS evidence from declared mileage.An observed route is not a declared distance.
Design choice
Use declared distance plus odometer readings/photos for mileage. Preserve ordered GPS evidence and simplify it for route display rather than treating a noisy signal as the commercial distance.
The trade-off
The interface has to explain which information is declared and which is measured. A route visualization is not proof that GPS captured every part of a trip.
03Make Core the authority.One set of rules for web and mobile.
Design choice
Centralize tenant context, permissions and business rules in the Hono backend. Keep routes, validation, services, repositories and response mapping separate.
The trade-off
Both web and app have to respect stable contracts. More interfaces should not create competing implementations of the same permission or business rule.
From the decision
to the implementation.
Core backend & APIs
Backend, data and infrastructure connecting the app and web panel.
Tracking & synchronization
Location SDK integration, batch flow investigation and route work.
Interface & API integration
Implementation and visual adjustments across web and app, connected to the core backend.
iOS & Android release
I contributed to preparing and publishing the ALP mobile app for iOS and Android.
This work spans the driver’s device, the operations dashboard and the app listings linked at the top of this case.