PalletFlow

The same mission means three different things depending on who is looking. To the operator it is a row in a queue with a cost and an assignee. To the driver it is one task at a time, at arm's length, possibly with no signal. To the partner it is a status and a date.

One interface for all three would have failed all three. Three disconnected apps would have meant three sources of truth.

One NestJS backend, one domain model, three clients over a shared component library. The shared layer is small on purpose — tokens, primitives, the API client, the auth flow. Everything above that is written per audience.

The driver app took the strictest constraints: large touch targets, a QR scanner as the primary interaction, and a UI that assumes the connection will drop. Scans queue locally and reconcile when the device is back online, because a driver standing in a warehouse should not be blocked by a signal bar.

• Admin dashboard — inventory, mission assignment, issue tracking, partner management
• Transporter app — mission list, task-at-a-time flow, QR scanning, proof of delivery
• Partner app — read-only mission and delivery visibility, scoped to the partner's own goods
• Radix UI primitives throughout, so keyboard and screen-reader behaviour came correct by default

NestJS modules split by domain behind a role-based guard layer, so a partner token can only ever resolve its own missions — enforced at the query level rather than by filtering the response.

Mission state moves through an explicit state machine, and every transition is recorded with its actor and timestamp. That is what turned issue tracking into a read over existing data instead of a separate feature.