AutoDirect
Connecting mineral shippers and transporters through one shared job record.
- React
- Firebase
- Firestore
- Transactions
The problem & my contribution
Mineral freight is often arranged through calls, messages, and personal networks. Shippers lack visibility of available capacity, transporters struggle to find return-leg work, and both sides need a shared record of progress. AutoDirect applies a ride-sharing marketplace model to this coordination problem, with shipper and transporter workflows in a React application.
- Keep assignment consistent when multiple transporters accept the same job.
- Represent seven named stages, with clear responsibilities and valid transitions.
- Keep infrastructure lightweight and communicate failures on unreliable connections.
From input to useful output
A shipper posts cargo details, pickup, destination, and timing. Transporters see the request and express interest; one accepts the work. The job then advances through loading, transit, delivery, and closure. Both parties follow the same Firestore record through real-time updates. Acceptance reads availability and writes the assignment in one transaction. If a competing acceptance has already claimed the job, the losing action reports that it is taken rather than overwriting the assignment. Client-side fallbacks provide clear feedback and safe retry paths when the preferred action cannot complete.
How the pieces fit
The documented architecture is a React single-page application communicating directly with Firebase. Firestore stores job records, streams status changes, and provides transactions for assignment. A dedicated custom server is not part of this documented design.
- React application
- Shipper job posting and tracking; transporter discovery, acceptance, and progress updates.
- Firestore
- Shared job records, real-time status updates, and transactional assignment.
- Client fallbacks
- Failure feedback and safe retries when the preferred path cannot finish; not a verified offline-sync system.
Engineering trade-offs
Check and claim atomically
Read availability and write assignment in one Firestore transaction.
Separate checks and writes leave a race window. Transactional assignment checks shared job state before committing, rather than treating competing requests as independent bookings.
Trade-off: Contention and failures need handling, alongside appropriate Firestore rules. The supplied document does not establish those rules.
Make state and failure visible
Use named lifecycle stages, a shared record, and explicit failure feedback.
Named stages clarify the next action. Shared updates reduce confirmation calls; fallback handling distinguishes saved actions from failed attempts.
Trade-off: The managed backend reduces maintenance but depends on Firebase and connectivity. Live GPS tracking remains a proposed extension.
Results, with boundaries
The supplied documentation reports a complete posting-to-closure workflow, transactional assignment, and graceful failure handling. It provides a concrete design account, but no repository, automated test results, deployment evidence, or measured operating outcomes were supplied for independent verification.
- Seven stages connect marketplace discovery with delivery and a retained completion record.
- The acceptance walkthrough explains the contention case: the first successful claim assigns the transporter; a later claimant receives a taken-job message.
Source: AutoDirect portfolio documentation supplied in October 2026. This condensed account distinguishes documented implementation from independent verification and proposed features.