Travel Booking Platform

The client came to us 14 weeks into a botched offshore build with no working product and a competitor about to launch in the same vertical. They needed a travel marketplace handling complex availability logic (overlapping bookings, timezone-aware inventory, cancellation windows), multi-currency payments with platform commission splits, and three client apps, web, iOS and Android, all ready for the investor demo in 90 days. The previous team had left a Django codebase with 14 circular imports and no tests.

We triaged the inherited code, salvaged the data model, and rewrote everything above it. Django REST Framework powers the API with Celery handling the async work: booking confirmations, partner inventory sync, payment webhooks. React runs the web storefront; React Native ships the mobile apps off an 85%-shared codebase so the team only writes platform-specific code for native pickers and payment sheets. Stripe Connect handles the four-way money flow (traveler to platform to host to tax authority) and the admin dashboard lets operators see every booking, dispute, and payout in one place.

• All three clients launched in the investor-demo window: 12 weeks from kickoff
• Processes bookings in 5 currencies with Stripe Connect split payments (platform takes 11%)
• Handles 10K+ concurrent availability checks at sub-200ms p95 response time
• Mobile accounts for 58% of all platform transactions in the first year

DRF won over FastAPI because the inherited data model was already Django-native and a rewrite would have cost us four weeks we didn't have. Celery with Redis handles the booking-confirmation saga, a workflow that touches partner APIs, Stripe, and notifications, and needs to recover cleanly when any one fails. React Native was the right mobile choice because the founder wanted both stores on launch day and had budget for exactly one mobile team. AWS ECS runs the containers; RDS handles Postgres; nothing exotic.