Tools07 / 12
TukTuk
A local ride platform pilot for an island
- Status
- Working, not deployed
- Role
- Design and development, end to end
- For
- Riders, concierge staff who book for guests, and drivers.
Problem
Small island fleets of tuk-tuks dispatch by phone call and memory. A pilot needs riders, dispatchers and drivers to share one live picture without the weight of a full ride-hailing stack.
TukTuk is a ride platform pilot made of a rider web app, an operations console and an Android-first driver app on one backend. It runs as a local demo and is not deployed.
Case study
The rider app is a PWA, the operations console serves dispatchers and concierge desks, and the driver app is built with Expo and designed for Android first. All three talk to one Fastify and PostgreSQL/PostGIS backend, with Redis used only for jobs and fan-out.
The project is a pnpm workspace with shared packages for contracts, domain logic and translations. It is a working local demo for evaluating the idea, with no real operations behind it.
Architecture
One Fastify backend on PostgreSQL with PostGIS. Presence and dispatch state live in Postgres, notifications use an outbox and a delivery ledger, and invariants are enforced in the database itself. Redis handles jobs and fan-out only.
Engineering decisions
- An original core instead of forking an existing ride-hailing project.
- Presence and dispatch state in Postgres, not in a cache.
- Outbox plus delivery ledger for notifications, so none is lost or sent twice silently.
- Invariants enforced in PostgreSQL, not only in application code.
Challenges & trade-offs
Keeping dispatch correct under load. A simulation with 250 drivers sending heartbeats guided the design.
Verified results
- p95 of 4.2 ms for heartbeats at 250 simulated drivers
- API suite: 237 passing tests; 55 test files overall
- Working local demo, not deployed
Status labels are factual: nothing here is presented as more finished than it is.