Inside RapidX: how Flutter, Laravel and Firebase fit together

If you're evaluating RapidX — or any super-app source code — the architecture matters more than the screenshots. It decides how easy the code is to extend, who you can hire to work on it, and what it costs to run.

Here's how the pieces fit.

The five products in the box#

RapidX ships as five cooperating products:

1. Rider app (Flutter) — rides, food, parcels and city travel in one app.
2. Driver app (Flutter) — trips and deliveries, bidding, earnings and gamification.
3. Restaurant app (Flutter) — menus, live orders, revenue and opening hours.
4. Admin panel (Laravel 11) — regions, pricing, promotions, subscriptions, AI insights.
5. Support desk + marketing site — a staff portal for live tickets and a public landing page.

All three mobile apps talk to one Laravel backend. There's no separate "food service" and "taxi service" to keep in sync.

Why Flutter for the apps#

• One codebase per app for Android and iOS, with native performance for maps and animations.
• A large hiring pool. Flutter is now a mainstream skill; you're not locked to a niche framework.
• Consistent UI across rider, driver and restaurant apps, so rebranding is a theme change rather than three separate projects.

Why Laravel for the backend#

• Laravel 11 + MySQL is boring in the best way: well documented, easy to host on any VPS, and familiar to a huge number of developers.
• Laravel Sanctum handles API authentication for the mobile apps.
• The admin panel lives in the same codebase as the API, so business rules (fares, zones, promos) are defined once.

Real-time: Firebase where it earns its place#

Some data changes many times a second — a driver's position during a trip. Pushing that through the REST API would be wasteful. RapidX uses:

• Firebase Firestore for live GPS during active trips and deliveries, so rider apps subscribe to updates instead of polling.
• Firebase Cloud Messaging (FCM) for push notifications: new requests for drivers, status changes for riders, new orders for restaurants.

The authoritative record of every trip and order still lives in MySQL. Firestore carries the fast-moving state; Laravel owns the business truth.

A simplified view of a live location update (illustrative, not the exact schema):

{
  "tripId": "58",
  "driverId": "d_1042",
  "lat": 31.5204,
  "lng": 74.3587,
  "heading": 128,
  "updatedAt": "2026-08-28T14:32:05Z"
}

Maps and pricing#

Google Maps powers geocoding, routing and distance for fare calculation — you bring your own API keys. Pricing rules (base, distance, time, minimums, surge windows, vehicle types) are configured per taxi region, and food delivery uses separate food zones drawn on a map, each with its own currency.

Payments#

Gateways are configured from the admin panel rather than hard-coded:

• Stripe (cards and subscription renewals), PayPal, Razorpay and MyFatoorah.
• A built-in wallet for riders and drivers — top-ups, trip and food payments, refunds and driver earnings.

Optional AI#

AI features are additive and need your own OpenAI or Gemini key:

• AI Insights — city health (utilization, wait times, cancellations), demand heatmaps and weekly summaries.
• AI Setup Wizard — proposes regions and vehicle setups for a new city and can load demo data.

The core ride and food flows work without any AI configured.

What this means for your team#

You want to…	You'll work in…
Rebrand the apps	Flutter theme, assets and app IDs
Change fares or zones	Admin panel — no code
Add a new payment gateway	Laravel payment service + admin settings
Add a new vertical (e.g. pharmacy)	Laravel models/API + a new Flutter module

Ready to look for yourself? The live demo runs the same build you download, and the admin panel is open to explore.