Mercor Driver Data Platform

Context

A driver-facing platform built across an Expo and React Native application with web support and a Django REST backend. Drivers can discover and apply to data-collection opportunities, pair dashcam hardware over Bluetooth, provision device Wi-Fi, review routes and drive history, upload receipts for AI-assisted extraction, and track earnings and payouts. The backend coordinates session and device authentication, GPS telemetry, drive recovery, route creation, distance calculation, and the earnings ledger across PostgreSQL, Redis, and S3-compatible object storage.

Role and scope

Full Stack Software Engineer: built the driver-facing Expo/React Native application and Django REST backend across device pairing, telemetry, route history, receipts, opportunities, and earnings.

Challenge

Drivers needed one reliable workflow for finding data-collection opportunities, connecting capture hardware, recording drives, submitting supporting receipts, and understanding what they had earned. The platform also needed to protect long-running drive sessions from device interruptions while keeping mobile and web experiences aligned.

Approach: Built a shared Expo application with file-based routing, responsive web support, secure session storage, BLE device pairing, Wi-Fi provisioning, map-based route views, receipt upload, and earnings screens. Implemented the Django REST API with session-token and device-token authentication, opportunity applications, PostgreSQL domain models, Redis-backed infrastructure, MinIO storage, Qwen2.5-VL receipt OCR, batched GPS ingestion, recoverable drive sessions, haversine distance calculation, route history, and automatic transaction creation.

Key decisions and trade-offs

• Used Expo and React Native with platform-specific map implementations so the same product could serve iOS, Android, and web while respecting native device capabilities.
• Separated user-session and device-token authentication so firmware could report telemetry without exposing user credentials.
• Made drive recovery and a database-level active-drive constraint part of the lifecycle because capture devices can reboot or reconnect during a drive.
• Kept receipt processing asynchronous and status-based so OCR failures could be surfaced without blocking the rest of the earnings experience.

Outcome

• One driver workflow connects opportunity discovery, hardware pairing, route history, receipt capture, and earnings.
• Shared mobile and web application supports platform-specific BLE, maps, storage, and navigation needs.
• Drive sessions can recover after device interruption and turn GPS telemetry into route history and earnings transactions.
• Receipt uploads move through a visible processing lifecycle with structured OCR results and verification states.

Stack

Stack used in this system · Full Stack Software Engineer