Mobile AppsCrosva Pty Ltd
YUFO Trade
Delivery App
A high-performance trade services marketplace that connects drivers and tradies through complex real-time delivery features, live location tracking, and seamless job management—built for the Australian market.
- Live
- yufotrade.com
- Built with
- Next.js · NestJS · Hono · React Native · Expo · tRPC · Prisma · PostgreSQL

Case study
YUFO Trade is an on-demand delivery marketplace for the Australian construction trade: tradies order materials and tools from nearby suppliers and have them driven straight to the job site. It is a three-sided product - tradies, drivers, and suppliers - and I engineered the platform across the mobile apps and the services behind them.
- Role
- Software Engineer
- Timeline
- Jun 2025 - May 2026
01
The problem
A tradie who runs out of material mid-job has to leave the site, drive to a supplier, and drive back. That round trip is unbillable time on a job that has already been quoted. Removing it meant keeping three parties in sync, in real time, on phones used outdoors.
- Supply runs pull contractors off a job site for hours, turning billable work into unpaid driving.
- An order is only useful when supplier stock, driver availability, and job site location all line up at the same moment - three-sided state that drifts out of sync easily.
- Stale inventory is worse than no inventory: ordering material that is not actually on the shelf breaks trust with the tradie, the driver, and the supplier at once.
- The app is used on-site - gloves on, in direct sun, on patchy reception - not at a desk, so a standard mobile UX would fail in the field.
- Naive live location tracking drains driver batteries and floods the backend once many deliveries are active concurrently.
02
The solution
01
One contract, three roles
Tradie ordering, driver dispatch, and supplier fulfilment run as role-specific flows across Expo on mobile and Next.js on web, sharing one tRPC contract so a change to a delivery's shape surfaces as a type error rather than a runtime bug in the field.
02
Battery-aware live tracking
Background location uses adaptive sampling and batched position updates rather than a constant per-driver stream, keeping tracking accurate without draining the phone a driver depends on all shift.
03
Delivery state machine
Every order moves through a strict sequence - placed, accepted, picked up, en route, delivered - so all three parties read the same status instead of reconciling it over the phone.
04
Real-time supplier inventory
Stock levels and pricing are surfaced at browse time straight from the supplier, so a tradie orders against material that actually exists rather than discovering the shortfall after dispatch.
05
Built for patchy reception
Job sites lose signal. Actions taken offline queue locally and reconcile when the connection returns, so a driver marking a delivery complete in a basement is never blocked by the network.
06
Mid-shift releases via OTA
Expo over-the-air updates put fixes on drivers' phones during an active shift, without waiting on an app store review cycle that a live logistics operation cannot afford.
03
Results & impact
- Tradies order from the job site instead of driving to a supplier, converting unbillable supply runs back into billable work.
- Live tracking gives concurrent deliveries one shared source of truth, removing the round of where-is-my-order phone calls between tradie, driver, and supplier.
- Real-time supplier inventory means orders are placed against stock that is genuinely available, protecting trust across all three sides of the marketplace.
- End-to-end type safety from PostgreSQL through Prisma and tRPC to both the Expo apps and the Next.js web surface means a schema change breaks the build instead of breaking a driver mid-delivery.
- Over-the-air updates let fixes reach drivers mid-shift, shrinking the gap between finding a field issue and resolving it.
04
Tech stack
Mobile
- Expo
- React Native
Web
- Next.js
Backend
- NestJS
- Hono
- tRPC
Database
- PostgreSQL
- Prisma ORM
05
Lessons learned
- A three-sided marketplace is a state-synchronization problem before it is a UI problem. The hardest work was not any single screen - it was guaranteeing that tradie, driver, and supplier never saw three different versions of the same delivery.
- Battery life is a product feature on a driver app. A tracking implementation that is technically correct but drains the phone gets force-quit by drivers, which silently destroys the tracking it was built to provide.
- Designing for the actual environment changes real decisions. Gloves, sunlight, one free hand, and dead reception are constraints that reshape tap targets, contrast, and offline behaviour far more than any style guide does.