Luggage Delivery App Italy: How We Built a Real-Time Gig Economy Platform

Lugxi solves a problem every traveler knows: arriving at an airport or train station with heavy luggage and no easy way to get it to your destination. Instead of dragging bags through unfamiliar terminals or queuing for overloaded taxis, travelers can request on-demand luggage pickup and delivery directly to their final point—with real-time driver tracking and transparent pricing.

The platform connects two distinct audiences: travelers who need luggage transported and drivers who can provide the service. Like any gig economy platform, Lugxi only works if both sides have a credible experience. Travelers need to trust that a driver will show up and deliver their luggage safely. Drivers need to trust that payment will process reliably.

That mutual dependency shaped every technical decision.

Building a two-sided gig platform requires solving the credibility problem before adding features. The same pattern appears in multi-audience platform architecture—where platform success depends on earning trust from both sides simultaneously.

This case study covers the key technical decisions that made Lugxi staging-ready: the real-time tracking architecture, the multi-tier route optimization, the payment reconciliation system, and the infrastructure setup on GCP Cloud Run.

1. The Problem: Luggage Transport That Leaves Travelers Stranded

Italian airports handled over 150 million passengers in 2024. A significant percentage arrive with luggage that needs to move from the terminal to a car, taxi, or hotel transfer—but the last 100 meters remain unnecessarily difficult.

Traditional solutions fail in predictable ways:

• Taxis require travelers to queue, load their own bags, and negotiate trunk space
• Shuttle services operate on fixed schedules and fixed routes
• Baggage storage solves the wrong problem for travelers who need their bags with them

The opportunity was clear: an on-demand luggage delivery service that works like ride-sharing, but for luggage. Travelers request pickup, a verified driver collects the bags, and delivery happens at the traveler’s destination—airport to hotel, hotel to train station, anywhere within the service area.

The technical challenge was not the concept. It was making the experience credible for both sides—real-time visibility, reliable payment, and consistent service that could be trusted enough to hand over your luggage to a stranger.

2. Technical Architecture: Monorepo for Speed and Consistency

Lugxi follows a monorepo architecture using PNPM workspaces, which allows sharing types and utilities across the three main applications while keeping deployment independent.

System Overview

The system consists of three distinct applications and a shared package layer:

• Lugxi (React Native mobile app) — traveler-facing app for requesting pickups, tracking drivers, and managing deliveries
• Lugxi-Backend (Express.js) — API layer handling business logic, route optimization, and third-party integrations
• Lugxi-Admin-App (Next.js 15) — internal dashboard for ops team to monitor deliveries, manage drivers, and handle exceptions

Tech Stack Table

Component	Technology	Version
Mobile App	React Native	0.81.5
Backend Framework	Express.js	4.21.2
Database & Realtime	Firebase / Firestore	13.1
Payment Processing	Stripe	17.6
Route Optimization	Mapbox Directions API	—
Deployment Target	GCP Cloud Run	europe-west8
Mobile SDK	Expo SDK	54

The shared packages (shared-types and utils-timezone) ensure type consistency across the monorepo. This was not an over-engineering decision—it was a direct response to the problem of drift between mobile apps and backend that slows down gig economy platforms when they scale.

The tech stack decisions here follow the same framework we use for all MVPs. For a full breakdown of why we choose specific tools for specific project types, see MVP Tech Stack 2026.

3. Route Optimization: Multi-Layer Fallback System

Route optimization in a gig economy delivery context has to handle failures gracefully. If the primary routing service goes down during peak hours, the entire platform cannot grind to a halt.

Capacity Planning

Before diving into route optimization, the system needed a capacity model. Luggage comes in different sizes, and a driver can only accept jobs that fit their vehicle:

Luggage Type	Volume (m³)	Typical Dimensions
Backpack	0.05	40L
Cabin bag	0.056	55L
Large suitcase	0.12	70-90L
Oversized	0.20+	>90L

The capacity limit is 10m³ per driver vehicle. The route optimizer validates that a driver’s current load plus the new pickup will not exceed capacity before accepting the job.

Three-Tier Fallback Strategy

The routeOptimizer.ts module implements a cascading fallback system:

1. Primary: Mapbox Directions API — Used for fresh route calculations when distance >500m or estimated time >5 minutes
2. Secondary: Google Maps API — Used when Mapbox is unavailable or rate-limited
3. Fallback: Haversine Distance — Used when both external APIs fail, calculates straight-line distance and estimates time at 30km/h average

The time window validation ensures drivers cannot accept pickups that are geographically or temporally impossible. A 30-minute minimum buffer between consecutive pickups prevents over-promising and under-delivering.

4. Smart ETA Monitoring: Bolt-Style Distance-Based Notifications

Real-time tracking in gig economy apps often fails in one of two ways: either it sends updates too frequently (draining battery and flooding the user) or it uses timestamps that drift and become inconsistent across devices. Lugxi takes a different approach: distance-based notification triggers with hybrid ETA calculation.

Firestore Real-Time Subscriptions

The driver’s location is written to Firestore every 5 seconds. The traveler’s app subscribes to this document via a real-time listener, which triggers local calculations rather than relying on server-side timestamp comparison.

// Hybrid ETA calculation pseudocode
function calculateETA(driverLocation, destination, lastMapboxUpdate) {
  const distance = haversine(driverLocation, destination);
  const timeSinceUpdate = Date.now() - lastMapboxUpdate;

  // Use Mapbox if data is fresh (>500m from destination or >5min since last update)
  if (distance > 500 || timeSinceUpdate > 5 * 60 * 1000) {
    return fetchMapboxETA(driverLocation, destination);
  }

  // Otherwise use internal speed calculation
  const recentSpeed = calculateRecentSpeed(driverLocation.history);
  return distance / recentSpeed;
}

Distance-Based Notification Triggers

The system sends notifications to the traveler at fixed distance thresholds—not time-based estimates:

Distance	Notification
1 km	”Driver is approaching”
200 m	”Driver is nearby”
50 m	”Driver has arrived”

Using fixed minutes (not timestamps) for ETA display ensures consistency across devices and time zones. A timestamp like “arrives at 14:32” can become stale within seconds; a distance-based trigger remains valid until the driver crosses the threshold.

This approach mirrors the Bolt-style notification model that travelers find intuitive: they do not need to interpret complex ETAs, just understand where the driver is relative to their pickup point.

The signal-first approach here—designing around observable events rather than estimated timelines—applies the same principle behind real-time signal-first design in crowdsourcing platforms.

Validating Driver Movement Toward Destination

A critical safety check: the system must confirm the driver is moving toward the destination, not simply stationary or moving away. This is verified by comparing consecutive location updates and calculating bearing. If the bearing deviates more than 90 degrees from the optimal route for more than 60 seconds, the system flags the delivery for manual review.

5. Payment Integration: Stripe Webhooks and Cron Reconciliation

Payment in a gig economy delivery context requires hold-and-capture semantics, not simple charge-on-demand. The money must be authorized when the driver confirms pickup and captured only when the traveler confirms delivery.

PaymentIntent Flow

Key Implementation Details

Idempotency: Every PaymentIntent creation uses an idempotency key derived from the delivery ID. This prevents duplicate charges if the mobile app retries the request due to network issues.

Authorization hold: The driver confirms pickup via the app, which triggers a Stripe authorize action on the PaymentIntent. The funds are held but not yet captured.

Capture on delivery: The traveler confirms delivery via the app, which triggers capture on the PaymentIntent. The funds are transferred to the driver’s account minus platform commission.

Status mapping: Stripe webhook events map to internal status:

• payment_intent.succeeded → PAID
• payment_intent.canceled → CANCELLED

Cron Reconciliation Job

A background job runs every 15 minutes to catch abandoned sessions. If a PaymentIntent was authorized but not captured within the timeout window (15 minutes from pickup confirmation), the cron job cancels it to release the hold on the traveler’s funds.

This prevents the common gig economy problem of funds being stuck in authorization holds indefinitely—a problem that erodes trust faster than almost anything else.

Payment architecture with guardrails mirrors the approach in AI as accelerator, not autopilot—using automation to handle routine tasks while keeping human oversight for edge cases.

6. AI Translation Service: OpenAI Structured Outputs

Luggage delivery in Italy means serving international travelers. The system needed to handle communications, push notifications, and driver instructions in 50+ languages.

Implementation

The translation service uses OpenAI’s GPT-4.1-nano with Structured Outputs to ensure consistent response shapes regardless of input language. Each translation request includes:

• Source language (auto-detected or specified)
• Target language
• Content type (notification, instruction, message)
• Text to translate

The Structured Outputs constraint ensures the model always returns a JSON object with translated_text and confidence_score, making downstream parsing reliable.

Error Handling

Translation failures map to proper HTTP codes:

• 429 → Queue for retry (rate limited)
• 500 → Fallback to English (graceful degradation)
• 503 → Use cached translation if available

This ensures that a translation API outage never blocks a delivery from proceeding.

7. Infrastructure and Deployment: GCP Cloud Run

The backend runs on GCP Cloud Run in the europe-west8 region (Milan), chosen for proximity to Italian users and compliance with EU data residency requirements.

Secret Management

All credentials (Stripe keys, Mapbox tokens, Firebase service account) are stored in GCP Secret Manager and injected into the Cloud Run containers at startup via environment variables. No secrets are stored in the codebase or in configuration files that could be committed to version control.

CI/CD Pipeline

Deployment follows a standard Cloud Build pipeline:

1. Build — Docker image built from Dockerfile
2. Test — Unit and integration tests run in Cloud Build
3. Deploy — Image pushed to Artifact Registry, Cloud Run service updated with new image tag

Rollback is handled by updating the Cloud Run service to point to a previous image tag—full blue-green deployment without downtime.

For a full checklist on hardening MVP infrastructure for production use, see Prototype to Product Hardening.

8. What Staging-Ready Actually Meant

Lugxi reached staging-ready when the following conditions were met—not just in theory, but in practice:

Real-Time Requirements Met

• Firestore listeners active: Both traveler and driver apps receive real-time updates within 2 seconds of a location write
• Notification triggers functional: Distance-based notifications fire correctly at 1km, 200m, and 50m thresholds
• ETA calculations verified: Hybrid ETA (Mapbox + internal) produces results within 5% of actual arrival time over 50 test routes

Background Jobs Operational

Three background jobs run reliably:

• ETA Monitor — Checks driver location every 10 seconds, updates Firestore, triggers notifications
• Route Planner — Recalculates optimal route when driver deviates >200m from planned path
• Stripe Reconciliation — Runs every 15 minutes, cancels stale authorizations, updates payment status

Complete Pickup Status Flow

The delivery lifecycle is fully implemented:

PENDING → DRIVER_ASSIGNED → DRIVER_EN_ROUTE → PICKUP_CONFIRMED →
IN_TRANSIT → DELIVERER_ARRIVING → DELIVERY_CONFIRMED → COMPLETED

Each transition is validated, logged to Firestore, and triggers appropriate notifications to both parties.

9. Reusable Playbook for Real-Time Gig Platforms

The patterns that made Lugxi staging-ready can be abstracted:

Core Architecture Pattern

Firestore real-time subscriptions → Hybrid ETA calculation →
Distance-based notification triggers → Stripe hold-and-capture

Key Decisions That Generalized

1. Three-tier fallback for route optimization — Ensures the platform works even when external APIs fail
2. Fixed minutes, not timestamps — Eliminates clock drift and timezone confusion across devices
3. Authorization-then-capture payment flow — Prevents payment disputes and fund-stucking issues
4. Background job separation — ETA monitoring, route planning, and payment reconciliation run independently

For parallel examples of platform MVPs that reached staging-ready with similar rigor, see EVOC: Crowdsourced Territorial Intelligence and Creative Two-Sided Marketplace Platform.

Metrics Snapshot

Signal	Result
Tech stack	React Native + Express + Firebase + Stripe
Platform type	Two-sided (travelers + drivers)
Region	Italy (Rome/europe-west8)
Route optimization	Mapbox → Google Maps → Haversine fallback
Payment capture	Auth on pickup, capture on delivery
Background jobs	ETA monitor, route planner, Stripe reconciliation
Notification triggers	1km, 200m, 50m distance-based

---

About Byte-sized

Byte-sized is an Italian boutique product studio that helps founders and SMEs turn ideas into real software—starting with MVPs built to learn fast from the market. We ship small but complete releases, keep scope and roadmaps clear, and reduce product and technical risk.

Want to build a real-time gig platform that reaches staging-ready credibility—without cutting corners on payment reliability or real-time tracking?

Contact us

---

Related Content

Continue Learning

• MVP Tech Stack 2026 — Our framework for choosing the right tools for delivery and gig platforms
• Why Crowdsourcing Platforms Fail — Signal-first design principles that apply to any two-sided platform
• AI as Accelerator, Not Autopilot — Using AI to handle routine tasks while keeping human oversight
• Prototype to Product Hardening — Infrastructure checklist for production-ready MVPs

See Another MVP Example

• EVOC: Crowdsourced Territorial Intelligence — Signal-first crowdsourcing with validation loops
• LyLife: Healthcare MVP in 30 Days — Fast validation in a different domain
• Creative Two-Sided Marketplace Platform — Multi-audience platform architecture

CTA

Next step — Ready for the next byte?

If you’re building a gig economy or logistics platform where real-time visibility and payment reliability are non-negotiable, we can help you build it right from the start.

→ Book a call
→ Explore services
→ Read Launchpad